ロバストネス図を活用したシステム設計 | 今さら聞けない！ゼロから学ぶオブジェクト指向 | Think IT（シンクイット）
ロバストネス図とは今回のテーマは「ロバストネス図」です。ロバストネス図とは、ロバストネス分析を行った結果のアウトプットとなります。ロバストネス分析とは、スリーアミーゴス（ソフトウェアの分野における統一モデリング言語（UML）を開発した3人）の1人であるイヴァー・ヤコブソンが提唱した分析手法で、システムを「バウンダリ」「エンティティ」「コントロール」の3つに分けて分析し（これらについては後述します）、要求モデル（ドメインモデル、ユースケースモデル）をロバスト（堅牢、強靭）にします。 ロバストネス図はUMLで定義されている13種類のダイアグラムには入っていませんが、UMLのコミュニケーション図やコラボレーション図を簡略化した形で簡単に書くことができます。ロバストネス図を書くことで要件の振る舞いが整理され、実装すべき点を明確にできます。 ユースケースシナリオを作成するロバストネス図のインプットは
「こんな受講者は嫌だ」、自動車ソフト技術者のリスキリング講師に聞く
無邪気に宣言するのはいいけれど、本当にできるのか――。自動車業界で活発化するリスキリング（学び直し）の動き。自動車メーカーや部品メーカーは機械（メカ）技術者をソフトウエア技術者へと転身させる計画を次々に打ち出す。研修プログラムをこなすことで、時代が求めるスキルを手に入れられるらしい。 メーカー側は「できる」と言う。なぜならソフト技術者を増やすための研修を用意したから。「とりあえず受けて」と上司から指示されてこなす研修に身が入らない筆者は、どうしても疑ってしまう。実態を知りたくて、リスキリングの研修を提供する側を取材してみることにした。 話を聞いたのはAKKODiSコンサルティング（東京・港）。リスキリング研修のサービスなどを提供する企業で、自動車メーカーや部品メーカーにも顧客が多い。公表しているところでは、デンソーの転身プログラムを支援する。 AKKODiSコンサルティング常務執行役員兼最
PHP: 定数 - Manual
定数 目次構文自動的に定義される定数マジック定数 定数は、値のためのID(名前)です。この名前が示すように、定数の値は スクリプト実行中に変更できません (マジック定数 は例外です。これは実際は定数ではありません)。 定数は大文字小文字を区別します。慣習的に、 定数は常に大文字で表記されます。 注意: PHP 8.0.0 より前のバージョンでは、 define() 関数を使って定義された定数は、 大文字小文字を区別しない場合がありました。 定数の名前は、PHP のラベルと同じ規則に従います。有効な定数の名前は、 文字またはアンダースコアで始まり、任意の数の文字、数字、 アンダースコアが後に続きます。正規表現で示すと次のようになります。 ^[a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*$ define() 関数を使うと、 予約語や有効でない名前の定数を定義す
技術的負債の四象限 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
エンジニアが「欲しいと選ぶ技術書」20冊、明らかになる
リベロエンジニアは5月6日、「エンジニアが"欲しい"と選んだ技術書ランキングTOP20」を発表した。調査は2020年2月～2023年2月、「エンジニアの自己学習を応援」キャンペーンに参加したエンジニアを対象にSNSで行われた。 調査による1～3位までのランキング結果は以下の通り。 エンジニアが"欲しい"と選んだ技術書ランキングTOP20 1位「リファクタリング(第2版):既存のコードを安全に改善する」、2位「ソフトウェアアーキテクチャの基礎―エンジニアリングに基づく体系的アプローチ」、3位「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック(Theory in practice)」だった。 「『どの技術書を買うべきか』悩まれるエンジニアは、ぜひ技術書選びの参考にしてみてください」と同社。 エンジニアが"欲しい"と選んだ技術書ランキングTOP20
グーグルの「Nest」と「Android」機器、スマートホーム規格「Matter」に対応
Googleは米国時間12月15日、「Google Nest」と「Android」のデバイスがスマートホーム標準規格「Matter」に対応したと発表した。これにより、他のメーカーのMatter対応デバイスとペアリングできるようになる。 Matterでは、スマートデバイスを制御するためのハブが必要となる。「Google Home」、「Google Home Mini」、「Nest Mini」、「Nest Audio」、「Nest Hub」（第1世代と第2世代）、「Nest Hub Max」、「Nest Wifi Pro」が、Matterのハブとして機能する。 「Google NestデバイスとAndroidデバイスが今日からMatter対応となり、皆さんが簡単かつ一貫した形でMatter対応デバイスを設定し、各自のニーズに最も適した形でスマートホームをカスタマイズできるようになった」と、Go
尼崎市「泥酔USB紛失事件」のてんまつ、こんなひどい報告書を読んだのは初めてだ
客によるITベンダーへの丸投げと、人月商売にありがちなITベンダーによる現場丸投げのなれの果てだな。調査報告書に目を通して、そんな感想を持った。何の話かというと、兵庫県尼崎市で再々委託先の技術者が泥酔してUSBメモリーを一時紛失し、そこに保存されていた全市民の個人情報を漏洩の危機にさらした例の事件の報告書である。ただもう1つ別の感想がある。「こんなひどい報告書を読んだのは初めてだ」。 この報告書は尼崎市が2022年11月28日に公表した直後に読んだ。人月商売のIT業界と客のIT部門などのアカンところを徹底的にえぐり出して、悔い改めてもらうことを仕事の本分と心得ている私だから、当然のことだ。で、読み始めたのだが、いろんな意味で「何じゃこりゃ」とあきれてしまった。BIPROGY（旧日本ユニシス）の客先、尼崎市の現場は、人月商売にありがちとはいえ、やりたい放題。尼崎市は究極の丸投げでベンダーマネ
サービス間通信のための新技術「gRPC」入門 | さくらのナレッジ
たとえば次のような「user.proto」というプロトコル定義ファイルを用意し、これを変換する例を見てみよう。 syntax = "proto3"; message Picture { uint32 id = 1; uint32 width = 2; uint32 height = 3; enum PictureType { PNG = 0; JPEG = 1; GIF = 2; } PictureType type = 4; } message User { uint32 id = 1; string nickname = 2; string mail_address = 3; enum UserType { NORMAL = 0; ADMINISTRATOR = 1; GUEST = 2; DISABLED = 3; } UserType user_type = 4; repeated
技術書を1冊読んで実践すれば、3年ショートカットできる 書籍・論文から「知識と経験」を学ぶコツ | ログミーBusiness
「スクラムフェス仙台」は初心者からエキスパートまでさまざまな参加者が集い、学び、楽しむことができるアジャイルコミュニティの祭典です。ここで登壇したのは、kyon_mm（きょん）氏。スペシャリストになれなくても成長する方法について話しました。全3回。2回目は、ジェネラリストを目指した経緯と書籍や論文で学ぶコツについて。前回はこちら。 「自分はジェネラリストがいいのかもしれない」という気づきkyon_mm氏：（スライドを示して）「どうしよう」と思った時に、「ちょっと考え直そう、どういうふうに考えたらいいかな」と思いました。その時に「スペシャリストとジェネラリストがいるな」みたいなことをぼやっと思いました。「スペシャリストは、特定の領域にメチャクチャ特化している達人で、その分野なら任せろという感じで、ジェネラリストは、いろいろな領域ができる万能な感じでだいたいそつなくこなします」という感じだなと
技術者の仕事を自らおとしめる愚か者たち、人月商売の「身分制」に異議あり
人月商売のIT業界の多重下請け構造は「多重ピンハネ構造」だ――。こんな趣旨の記事をこの「極言暴論」で何度か書いてきた。すると、「SIerの技術者と下請けITベンダーの技術者ではやっていることが違うので、待遇に差があって当然だろ」という文句が必ず何件か来る。「私たちが下請け技術者の仕事をつくってやっている」と暴言を吐く連中よりはましなのだが、私から言わせれば「何を言ってんだか」である。 もちろん、仕事の内容や能力が異なれば、報酬などの待遇が違って当たり前である。文句を言ってくる人は「やっていることが違うので待遇が違って当たり前」と言い切るのだから、優秀なプロジェクトマネジャーかSEなのだろう。もしプロマネなら反対に聞いてみたいことがある。それは「だったら、何で年収1000万円前後の安い給料で満足しているのか」ということだ。本来なら2000万円以上、大規模案件を切り回せる人ならば3000万円を
生き残る技術の見極め方、定着したオブジェクト指向としなかったSOAの違いとは
新技術が次々と登場するIT業界。ソフトウエア開発者として10年後も活躍するためには、必要なノウハウやスキルをどのように見極め、身につければよいのか。長きにわたって活躍しているIT技術者に自らの経験を明かしてもらった。 今回は、IT業界で30年以上の経験を持ち、ウルシステムズのソフトウエア開発者兼マネジャーとして活躍してきた平澤章氏に聞いた。平澤氏は長く読み継がれている『オブジェクト指向でなぜつくるのか』（日経BP）の著者でもある。 （聞き手は田島 篤＝日経BP コンシューマーメディアユニット） IT業界では、新しい技術が頻繁に登場します。当然ながら、長く活用されるものもあれば、消えていってしまうものもあります。それらの見極め方はあるのでしょうか。 一般論として偉そうなことは言えませんが、1つの例でお話しします。オブジェクト指向は、ソフトウエア開発手法として定着し、長く活用される技術になりま
プログラマが知るべき97のこと/分別のある行動 - Wikisource
Kevlin Henney(編)、和田卓人(監修)『プログラマが知るべき97のこと』(オライリー・ジャパン、2010年)を出典とする。各エッセイはCC-by-3.0-USによってライセンスされている。 どんなに余裕あるように見えたスケジュールでも、実際に作業を始めれば、必ずどこかで追い詰められた状態になるものです。そして、同じことを「正しくやる方法」と「手早くやる方法」があれば、後者の方が魅力的に見えてしまうことはよくあります。後者を選べば、後で修正が必要になるとわかっていても、その時は「必ず、すぐに修正しよう」と自分に誓うでしょう。プロジェクトチームのメンバーや、顧客などに修正を約束することもあります。約束した時点ではもちろん、絶対に約束を守るつもりでいます。次のイテレーションなどが修正のチャンスなのですが、実際にイテレーションが始まると、また新たな問題が起きてそちらに注力してしまい、結
DLL地獄 - Wikipedia
出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2024年2月） 独自研究が含まれているおそれがあります。（2024年2月） 出典検索?: "DLL地獄" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL DLL 地獄（ディーエルエルじごく）とは、DLL や COM コンポーネントなどのバージョンアップなどに伴い、それ以前のバージョンの DLL/COM コンポーネントなどに依存して動作するアプリケーションが動作しなくなる現象のことである。コンピュータ業界においては "DLL HELL" と呼ばれる場合が多い。Windows 以外の オペレーティングシステム (OS) で発生するものについては "Dependency Hell" の名称がよく使われる。 原理的には動的リンク
ASP.NET でのアセンブリ DLL 読み込み - マイクロソフト系技術情報 Wiki
概要 † システムの運用中に、誤ってASP.NETのbinフォルダにDLLファイルをコピーしてしまうなどの問題でシステム障害を発生させてしまうという可能性があるようです。 このため、ココでは、ASP.NETでのbinファイルからのアセンブリ（DLLファイル）読み取りについての仕組みを説明します。 ↑ 1. はじめに † ASP.NET のアセンブリ *1 DLL 読み込みは、 Windows フォームなど他の技術によるアプリケーションのアセンブリ DLL 読み込みとは異なる方式が採用されている。 この点を配慮せず ASP.NET のローカル bin フォルダ内へむやみにアセンブリ DLL を大量登録すると、思わぬ弊害を生じる場合がある。 ここでは ASP.NET のアセンブリ DLL 読み込み方式と、それにより生じうる弊害などについて説明する。 特記なき限り、以下は ASP.NET Web
だから、「COBOL」の問題じゃないってば | おごちゃんの雑文
日経コンピュータの馬鹿がまた俺に喧嘩を売る気らしい。 [3]COBOL資産を守って、若者の可能性をつぶす愚 この手の話は既に何度も言ってるので、繰り返しにしかならないのだが、別に「COBOL」が悪いわけじゃない。 それはCOBOLのせいじゃない COBOLは「負の遺産」なんかじゃない 言いたいことはこれらのエントリで言い尽しているのだが、問題は「COBOL」という言語にはない。ある程度歴史を持ってしまった汎用言語は全て同じ危険を持っている。 件のエントリでは「COBOL資産」はあたかも「負債」であるかのようなことを言われているのだが、それ自体は特に負債ではない。そもそも私は、 技術的負債 とかって言葉は嫌いだ。技術者の血と汗の塊を「負債」呼ばわりするなぞ、失礼の極みだ。 件のエントリで問題視するべきなのは、そこじゃない。てか、実のところ件のエントリはそこに触れているのに、力が足りない。 「
技術系メーリングリストで質問するときのパターン・ランゲージ
目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー＆ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま
Post by @shyouhei
ところでPerlリスクですか。まあ、あるんじゃないですか。ぶっちゃけ。でもさあ、さすがにPerlしか書けない人たちは転職先の選択肢のなさくらい自覚してると思う。なのでPerlがどうとかいう話はしないです。各自でどうぞ。 でね、ポイントはそこじゃないだろうと思うわけですよ。どんな選択をしても同様のリスクはあるんですよ。たとえばMacromedia ShockwaveでLingoで作ってたソフトとかさあ。今ではだれもメンテできないでしょう? だから今隆盛をきわめてる技術で作ったものが、何年か後にリスクになるってのは、それはそういうものなんですよ。べつにPerlに限らん。Perlはたまたま今そういうフェーズってだけで、明日は我が身ですよ。hamlとかsassとか。
コンピュータ対人間のクイズ対決、1回戦は同点
米IBMのコンピュータ「Watson」と人間のクイズ対決が始まった。3日にわたる対戦の初戦は同点に終わった。 Watsonは2月14日、人気クイズ番組「Jeopardy!」でクイズ王ブラッド・ラッター氏、ケン・ジェニングス氏と対戦した。1日目の成績はWatsonとラッター氏がそれぞれ5000ドル獲得、ジェニングス氏が2000ドルだった。Watsonはビートルズの曲や文学作品の登場人物などに関する質問に答えたが、Olympic Oddities（オリンピックに関する変わった出来事）の分野ではうまく答えられなかったという。 Watsonは、IBM創設者トーマス・J・ワトソン氏にちなんで命名されたコンピュータ。「迅速かつ正確に自然言語での質問に正解する」という人間の能力に対抗することを目指して開発された。1月に行われたJeopardy!の練習ラウンドではクイズ王に勝利している。 Watson対ク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Oracle Technology Network Development and Distribution License Terms