Jackson使い方メモ - Qiita
package sample.jackson; public class Hoge { public int id; public String name; @Override public String toString() { return "Hoge [id=" + id + ", name=" + name + "]"; } } package sample.jackson; import com.fasterxml.jackson.core.JsonProcessingException; import com.fasterxml.jackson.databind.ObjectMapper; public class Main { public static void main(String[] args) throws JsonProcessingException { Hog
OpenJDK のライフサイクルおよびサポートポリシー - Red Hat Customer Portal
インデックス 概要 OpenJDK のライフサイクルおよびサポートポリシー OpenJDK の更新リリース日 OpenJDK のライフサイクルの日付と RHEL のバージョン OpenJDK のライフサイクルの日付と Windows のバージョン OpenJDK エンタイトルメント Eclipse Temurin の Red Hat サポート Eclipse Temurin のライフサイクルおよびサポートポリシー Eclipse Temurin サポートのエンタイトルメント よくある質問 (FAQ) および参照情報 このアーティクルの情報は、随時変更される可能性があります。 概要 OpenJDK (Open Java Development Kit) は、Java Platform Standard Edition (Java SE) のオープンソース実装です。アップストリームコミュニティ
ソフトウェアドキュメント作法 - maru source
こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました！ #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、
k-method.jp - このウェブサイトは販売用です！ - k method リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
「技術的負債」とは何か。原典とその対応策を探る
負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,
凝集度 - Wikipedia
凝集度（ぎょうしゅうど、コヒージョン、cohesion）とは、情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いである。IPAが実施する情報処理技術者試験では、強度(きょうど、ストレングス、strength)という言葉が使われる。凝集度は順序尺度の一種であり、「凝集度が高い」とか「凝集度が低い」といった言い方で使われる。凝集度の高いモジュールは、堅牢性、信頼性、再利用性、読みやすさなどの点で好ましく、凝集度の低いモジュールは保守/評価/再利用/読解が難しいため好ましくないとされる。 凝集度は結合度と組み合わせて議論されることが多い。凝集度が高いモジュールは他との結合度が低いことが多く、逆に凝集度が低ければ結合度が高くなる傾向がある。ソフトウェアの品質を凝集度と結合度で表す手法は、Wayne P. Stevens（英語版）、Glenfold J
120年ぶり民法改正へ、システム開発費「高騰」のリスク
約120年ぶりに債権法を抜本的に見直した改正民法の施行が、約4カ月後の2020年4月1日に迫っている。改正によりIT業界で新たな火種となりそうなのが、ITベンダーが納品した情報システムに対して、ユーザー企業が無償改修や賠償を請求できる期間が実質的に延長される点だ。大手ITベンダーや業界団体は対応に乗り出しているが、システム開発費が「高騰」するリスクをはらんでいる。 改正民法は2017年に国会で成立した。売買やサービスなどの「契約」に関するルールを定めた債権法を約120年ぶりに抜本的に見直す。建築業界と並んで大きな影響を受けるのがIT業界だ。ITベンダーとユーザー企業それぞれで対応が必要になる。 最長10年間、ユーザー企業は無償対応の請求が可能に ユーザー企業とITベンダーが交わすシステム開発の契約形態は大きく2つある。ITベンダーが成果物に対する完成義務を負う「請負」と、ユーザー企業が設計
人工知能の運用・保守に関するノウハウを総まとめ 『人工知能システムのプロジェクトがわかる本』
『人工知能システムのプロジェクトがわかる本 企画・開発から運用・保守まで』は、まだ世にほとんど存在しない人工知能の運用・保守に関するノウハウを詰め込んだ教科書的な1冊です。 本書は開発者よりもむしろ、これから自社システムに人工知能を導入したいと考えている方や、実際に音頭を取るプロジェクトマネージャー向け。人工知能システムの特徴や注意点をまとめ、企画書やベンダーへの提案書の書き方、トライアルの手法や要件定義のポイントもしっかり解説しています。 付録には自社システムに人工知能を導入する際の参考になる、「開発提案書」や「トライアル分析提案書」などのすぐに使えるテンプレート集も用意しました。 本書を通してプロジェクトや開発状況の進捗における良し悪しを判断できる知識を身につけることで、開発者・ベンダーに改善や要望を的確に伝えられるようにもなるでしょう。 人工知能を育てるという視点に立ち、人と協調して
無料のシステム開発テンプレート集（Excel版）: ある SE のつぶやき
はじめに システム開発を効率よく進めるための１つの方法として、システム開発のテンプレートを使用することがあります。 ですが、システム開発のテンプレートは企業内で閉じてしまっていてなかなかインターネットで公開されることはありません。 ですので、システム開発で使用するであろうテンプレート集を Excel で作成して公開します。もちろん無料で商用利用可能です。改変も OK です。 プロジェクト管理用 スケジュール管理などのプロジェクト管理用のテンプレートはなかなかないのですが、プロジェクト管理の補助となるようなテンプレートを用意しました。 プロジェクト管理ツールは、別記事の「フリーで使えるプロジェクト管理ツールまとめ」をご参照ください。
【悲報】客先常駐システム開発で今もステップ数によるバグ検出数基準が使用されていることが判明 | 株式会社アクシア
お盆休みに入る前にTwitterに以下のツイートを投稿しました。 ステップ数で評価しようとするどこかのシステム開発会社みたいだなｗ https://t.co/67ujbhVoUn — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) August 10, 2017 あるんですよ。一番困ったのはステップ数に応じて「検出されるはずのバグ数」という指標もあって、その数の分だけバグが検出されないと試験が正しく実施されていないと判断されてしまうことがありました。プラグインで自動生成されるコードにまでその指標を押し付けられ…バグなんて出るはずもなく…。 https://t.co/oM4zT3oolb — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) August 10, 2017 私自身が客先常駐の現場でシステム開発に携わったのはフリーランスの頃なのでも
Eclipse+Maven という便利な開発環境をインストールからプロジェクト作成まで - Qiita
Eclipse Kepler (4.3.2) SR2 Packages で説明する Mavenは何が便利？ Mavenがjarとかライブラリをダウンロードしてくれる 使いたいライブラリを個別に集めなくてもいい。 使いたいライブラリに関連する別のライブラリも集めなくていいい。 他の開発者にわざわざライブラリを渡さなくてもいい。 ライブラリのバージョンが上がっても、バージョン番号をいじるだけ。 ライブラリの元のソースコードもMavenがダウンロードしてくれる。 Jenkinsを使っていたら、jenkinsはMavenとの連携は簡単。 ダウンロードされたライブラリはローカルディスクのライブラ置き場で保管され、必要に応じて使われる。 Eclipseのビルドパスに勝手に追加してくれる。共同開発者も含めてビルドパス管理不要になる。 複数のプロジェクトのライブラリの種類やバージョンを１箇所で管理できたり
pilgrim-lifestyle.com is Expired or Suspended.
「 pilgrim-lifestyle.com 」のページは、ドメインが無効な状態です。 ウェブサイト管理者の方はこちらから変更・更新を行ってください。 「 pilgrim-lifestyle.com 」is Expired or Suspended. The WHOIS is here.
UML入門 - IT専科
UML（Unified Modeling Language）とは、様々な開発現場で使用されている設計書の書式を統一する目的で規定された言語で、1997年にOMG ( Object Management Group ) により標準化されました。 但し、UMLによる標準化はあくまで表記方法であって、開発手法の方法論ではありません。 UML2.0では表記方法を以下のように分類しています。 構造に関する表記 振る舞いに関する表記 構造に関する表記 ・クラス図（Class Diagram） クラス構造を表現します。 ・オブジェクト図（Object Diagram） クラスをより具体化したオブジェクトで表現します。 ・パッケージ図（Package Diagram） クラスなどをグループ化し整理された関係を表現します。 ・コンポジット構造図（Composite Structure Diagram） クラ
ANA、国内線の旅客システムをオープン化、34年間のメインフレームの歴史に終止符 | IT Leaders
30年以上にわたり使い続けたシステムを入れ替える。企業ITに携わる人間ならば、その困難さを想像するのは難しくないはずだ。このほどANAは、8年間の歳月をかけて、国内線の予約、発券、搭乗業務を支える旅客システムをオープン化。34年間、ビジネスを支えたメインフレームに別れを告げた。プロジェクトの指揮官に話を聞く（文中敬称略）。聞き手：田口 潤 IT Leaders発行人 Photo：陶山 勉 ――今回、8年間にわたる国内旅客システムの刷新という大規模プロジェクトを終えた訳ですが、もともと、いつ頃から検討を始めたのですか？金子：“次”を考え始めたのは、2000年頃だったと思います。30年以上にわたって、メインフレームを使い続けてきましたが、そのころから限界を感じ始めていたのです。 コストについては、必要経費ですから、それほど問題視していませんでしたが、むしろ、技術者の確保には頭を悩ませていました
なぜプロジェクトマネジメントは機能しないのか
みなさん、はじめまして。プロセスデザインエージェントの芝本秀徳です。本特集では、システム開発などのプロジェクトを成功に導くための大切な要素である「プロセス設計」と、そこから展開する「プロジェクトマネジメント」について解説していきます。まずは自己紹介を兼ねて、なぜ私が専業コンサルタントとしてこれらを追い求めることになったかというところから話を始めましょう。 「デスマーチ」体験からプロセス設計の重要性を知る 大学卒業後、私はソフトウエアエンジニアとして、ソフトウエアベンダーに入社しました。新入社員研修が終わり、その後はひたすら組み込みソフトウエアのテスト業務に取り組む日々が続きました。これが数カ月ほど続いた後、初めて開発メンバーとして参加したプロジェクトが、まさに“デスマーチ”となったのでした。 いつ収束するとも分からない不具合。本当の納期は客先の担当課長だけが知っていて、私たちは設定されたム
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
プログラマの値崩れ - プログラマーの脳みそ
pixivと仕事の値崩れと - プログラマーの脳みそは「絵を描く」という仕事の値崩れとそれを防ぐにはという話題だった。僕はプログラマなので、当然ながらプログラマの仕事の値崩れについて考えを巡らせる。 需要と供給 プログラマというのは人材不足だ。そして頭数は余っている。どういう事かといえば、プログラマの質というのは総じて低いのだ。 SI業界(注文に応じてシステムをフルオーダーで開発する業態)では、「プログラマ≒プログラムを書く人」「SE = システムエンジニア ≒ お客さんの要望を取りまとめる人」ってカテゴライズがされてて、プログラマ ＜ SE という扱いになっていることが多い。 SI業界で必要とされるプログラミング技能は総じて低い。というか、業務用のプログラムってのはその8割はたいした技能が必要ないプログラムで出来ているといっていい。人手がかかり面倒くさい作業を人海戦術でこなしている、とい
XDDPと言う派生開発 - プログラマの思索
初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。 本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。 以下、メモ書き。 【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。 ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。 駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。 影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。 清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。 人体でも、風邪を引いた場合、抗生剤を飲む。 しかし、抗生剤は人によっては免疫機能が
アジャイルな見積りと計画づくり - idesaku blog
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ Mike Cohn マイク コーン 安井 力 毎日コミュニケーションズ 2009-01-29 売り上げランキング : 110658 Amazonで詳しく見る by G-Tools 見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。 おそらく、『アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング』と並んで、現代のアジャイル開発における最重要の一冊。あまりにすばらしい内容なので、毎日持ち歩き、たくさんブックダーツを打ちまくった結果、こんなにくたびれてさせてしまった。 アジャイルプロセスを導入しようとして挫折した人は多いと思う。何を隠そう、自分もそうだ。いったいどこで躓いてしまうのだろう？ 「ペアプログラミング」や「スタンドアップミーテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://lumber-mill.co.jp/gallery/view/tips/other/basicSpec