永遠のJava
Javaは、COBOLに代わる「システム開発のデファクトスタンダード」として確固たる地位を確立した。一方で、イメージの悪さや設計の古さといった問題も抱える。Javaの現状と最近の改良点、賢い使い方などをまとめる。 第4回 突然の高額ライセンス料請求のワナ、企業がJavaを賢く利用するには Javaプログラムの開発・実行に欠かせないのが、JDK（Java Development Kit）だ。現在、様々なベンダーがJDKを提供している。しかしJDKごとにサポート期間や料金が異なる。適切なJDKを選択しなければ、高額なライセンス料の請求につながりかねない。 2024.05.10 第3回 「AI分野に弱い」との汚名返上なるか、Javaで着々と進む機能強化 システム開発で確固たる地位を築いたJavaだが、AI（人工知能）やデータ分析といったはやりの分野で後れを取っている。ただしJavaも手をこまぬい
VSCodeでプロジェクトを開くとき、ついでにいろいろやる方法
この記事は GMOアドマーケティング Advent Calendar 2023 16日目の記事です。 こんにちは。GMOアドマーケティングのK.Mです。 VSCodeでプロジェクト（ワークスペース）を開くとき、その開発をするために必要となるいろんなこと（サーバー起動やらログtailやらブランチ整備やら…）をついでに自動でやれたら良いなと思います。 そんなときは tasks.json です！ というわけで今回は tasks.json を試してみます。プロジェクトを開くだけで周辺のいろんな準備もまとめてやってしまえるよう効率化したいと思います。 let’s try! VSCodeを開いてメニューの ターミナル > タスクの構成 から適切なものを選んで進みます。シンプルなテンプレートが得られるので、必要に応じてカスタマイズしていきます。 例として開発用サーバーを起動するようにしてみます。 { "
Storybookとは？Storybookを用いたフロント開発
はじめに 半年くらい前にプロジェクトにStorybook及びChromaticを導入したのでその知見を今更まとめたいと思います。Storybookに触れたことがない方・Storybookの導入を検討されている方向けの記事になります。 ChromaticはStorybookを用いた非常に強力なサービスです。Chromaticの記事も書いたので以下をご参照ください。 Storybookとは何か？ Storybookは「UIカタログ」です。それぞれのUIコンポーネントをブラウザで手軽にチェックすることができます。React以外にもVueやAngular、Svelteなどにも対応しています。オープンソースで無料のサービス（モジュール）です。 以下のように開発中のコンポーネントをブラウジングできます。 Storybookの利点として以下の点が挙げられます 手軽にUIのテストができる サーバー側の準備
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
個人開発アプリにウィジェットを追加した話
はじめに こんにちは。先日個人開発したアプリにウィジェットを追加したので、その過程について書こうと思います。ウィジェットを追加したい方の参考になれば幸いです。また、SwiftUIの基本的なことについては、自分の過去の記事でコピペしてそのまま動くものを多く残しているのでそちらを参考にしていただければと思います。なお、書いている人は仕事としてアプリ開発を行ったことがありません。稚拙なコードや理解の浅い部分も散見されるかと思いますが、その際はコメントなどで指摘していただきたいです。 アプリの紹介 マンセルカラーから色を選択し、RGB値とカラーコード を取得するとても簡単なアプリです。全てSwiftUIで作っています。ソースコードや構成についてはこちらで書いています。 手順1 Widget Extensionを追加する File -> New -> Targetから,Widget Extensio
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Technologic Arts | カタリシス法によるコンポーネントベース開発
カタリシス法は、ICON Computing社のDesmond D'Souza氏と、Trireme社のAlan Cameron Wills氏が提唱している方法論です。D'Souza氏は、UMLチームの一員としてOMGでのUMLの提案に参加しており、UMLのコントリビュータとして活躍しています。カタリシス法の特徴は、コンポーネント指向とフレームワークを取り入れ、エンタープライズレベルのシステムにまで対応できる点です。また、システム実装が分散オブジェクト技術のCORBAやDCOMである場合は、設計から実装へシームレスに落とし込むことができます。もちろん、UMLベースの表記を採用しているため、UMLの知識があればカタリシス法に登場するダイヤグラムを問題なく理解することができます。 一般的にコンポーネントという言葉から連想されるのは、マイクロソフトのDCOM(Distributed Comporn
プロジェクト・マネジメント — metametaweb
プロジェクト・マネジメントに関する資料室 IEEE830-1998 ソフトウェア内部仕様書 (SRS) の書き方 (IEEE830-1998のあらまし) IEEE1362-1998 ソフトウェア外部仕様書 (ConOps) の書き方 (IEEE1362-1998のあらまし) IEEE1058-1998 プロジェクト管理計画書の書き方 (IEEE1058-1998) の注釈付きあらまし ソフトウェア開発におけるシステム要求仕様書の書き方 (ハンドアウト) 2006年10月26日, ISSで行ったセミナ「ソフトウェア開発におけるシステム要求仕様書の書き方」の講義資料です オブジェクトとしてのソフトウェア・セル 最近, ソフトウェア・セル生産が話題になりつつあります. ソフトウェア・セルをアジャイル/オブジェクトの立場からみるとこうなります ウォーターフォールからアジャイルへ 2006
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（クラウド時代の受託開発編）
SIビジネスの本質は保険屋であり、受託開発でアジャイル開発が失敗するのは受託開発が製造業だから。11月19日に行われた楽天テクノロジーカンファレンスでの講演「プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン」では、ソニックガーデン代表取締役社 倉貫義人氏によるこのような示唆に富む内容が語られました。 さらに倉貫氏は、ソニックガーデンで行っているクラウド時代の受託開発の新しいモデルについても詳しく紹介しています。 同氏の講演の内容を、配信されたUstreamの動画を基にして紹介しましょう。 （本記事は「プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（SIビジネスの本質編）」の続きです） なぜ受託でアジャイル開発がうまくいかないか 新規事業でやったのが、クラウドでのソフトウェア提供です。SkipとYouRoom。 ビジネス領域でいうとクラウドベンダーという
MSDN マガジン: BDD 入門: SpecFlow と WatiN によるビヘイビア駆動開発
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 SpecFlow と WatiN によるビヘイビア駆動開発 Brandon Satrom サンプル コードのダウンロード 自動単体テストは、ソフトウェア開発の現場でますます広く実施されるようになり、さまざまなテストファースト手法の導入も進んでいます。どのテストファースト手法にもそれぞれ、開発チームにとってメリットもあれば課題もあります。しかし、いずれも "設計としてのテスト" という考え方の確立を目指しています。 ただし、テストファースト世代でも、ユーザーの行動 (ビヘイビア) を表現する方法については、システムの言語 (ユーザーの言語とはかけ離れた言語) で書かれた単体テストを利用する方法が主流でした。この
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
浅田真央はソニー製でキムヨナがLG電子製なんだなと思ったと同時に日本のメーカーがiPodを作れなかったことを思い出した。 ：村上福之の「ネットとケータイと俺様」：ITmedia オルタナティ
国内のネットのオリンピックの審査結果の評判を聞いているとこんな感じだ。 ・キムヨナは採点基準を追求した点取り型の演技で技術的には浅田真央の方がレベルが高い。 ・浅田真央は世界初のトリプルアクセルを成立させたが、採点基準の上では低くなる。 なんだか、いつもヘンな技術にこだわってスカタンをする日本のメーカーみたいで笑ってしまった。 ここでも言われているように、日本以外の国では、韓国のデジタル家電の方が日本製品よりメジャーなモノが多い。価格も安いし、ユーザーのニーズに沿った製品を作ってくる。ヘンな機能を追及したりしていないからだ。 浅田真央のように、日本のメーカーはヘンに技術にこだわることが多い。 たとえば、ソニーがビデオのベータマックスを出したとき、なぜか「カセットの大きさ」にこだわっていた。彼らは、文庫本サイズにこだわった。おかげで初代ベータは1時間しか録画できなかった。そこはこだわるべき
Windows Phone 7、デベロッパーの前評判は？
待ってました！というわけでもないようで...。 様々な期待を背負っているWindows Phone 7ですが、アプリがなければ何もできません。では実際、アプリを開発するデベロッパーからはどう思われてるんでしょうか？ IMアプリを開発するBeeJiveのCEO、カイ・ユーさんは｢鳴り物入りだけど、全然ダメでしょうね。マイクロソフトは大企業すぎて、ツールも人も、細分化されすぎなんですよ｣としています。 一方で、Windows Phone 7を支持していると言えるのは、iPhoneとBlackBerry向けのPersonal Assistantなどを開発しているPageonceのCOOです。彼はマイクロソフトが｢Windows Phone 7と統合可能なすごいプラットフォーム｣をすでに持っているのではないかと期待しています。 が、Windows Mobile向けにメディアソフトウェアを開発してい
【ハウツー】Moqを活用して.NETでモックを使ったテストを行う (1) Moqとは | エンタープライズ | マイコミジャーナル
はじめに Moqは、.NETで注目を集めているモックライブラリです。MoqはシンプルなAPIを持ち、Visual Studioのインテリセンス機能を活用できるため、初心者でも簡単にモックを使い始めることができます。 モックとは モックを使うと、未実装のクラスやインタフェースを、あたかも実装済みのように振る舞わせることができます。また、本番環境とテスト環境で振る舞いを変えたい場合にも使用できます。例えば、外部リソース(サーバやWebサービス)と連携する場合や、環境によって異なる要素(現在時刻等)のテストに役立ちます。 Moqとは Moqはオープンソースのモックライブラリで、モッキュ(Mock-You)と発音します。.NET環境においてはNMock、TypeMock.NET、EasyMock.NET、RhinoMockなど多くのモックライブラリが存在しますが、Moqは初心者でも覚えやすい簡単な
株式会社マジカジャパンの羽生章洋が書いてるブログ:業務システムとSIの未来 - livedoor Blog（ブログ）
先日GAEJについて少しだけ触れました。その後色々と眺めるにつれて、改めて業務システムやSI（システムインテグレーション）というものの未来について考えを深めています。 ではそのオリジナルな売り方の工夫をして、そしてボリュームをこなさないといけないとなると、どうやってそれをさばくのか。当然人海戦術では回らなくなりますし、そもそもフロントエンドがWeb（クラウド上のサービス）なのに人手を介して行う理由はありません。独自の販売管理システムが欲しくなるのは必然でしょう。 独自の販売管理システムが必要だとなったときに、どうやって開発するか。パッケージをカスタマイズ出来ればいいのでしょうけど、フィットするものが見つからなければどうするか。やはりオリジナルで作ることになるでしょう。ですから、業務システムを作るということ自体は多分なくならない。 ただ、では誰が作るのかということを考えると、以前にも書いたよ
プログラマに必要なたった一つの力
この記事は小飼弾氏が，2008年3月24日に発売した日経ソフトウエア2008年5月号の特集「はじめてのプログラミング」向けに著したものの再掲です。記述された内容は，執筆当時の情報に基づいています。 あなた，プログラマになりたいんですって？ 本当に？ 本当に？ もう一度尋ねます。本当に？ 3回も念を押したのには，理由があります。このあと，さらに念を押します。この手紙を読み進めれば，あなたにもその理由がおわかりいただけるかと思います。 「日経ソフトウエア」を読んでいただいているからには，あなたは「プログラマ」という職業について，ある程度のイメージをお持ちだと思います。プログラマ，プログラムを作る人。では，プログラムって何でしょうか？ その定義は，これをお読みになった人の数かそれ以上存在しますが，私にとっての定義は「コンピュータが仕事をできるようにすること」です。ご存じだとは思いますが，コンピュ
株式会社マジカジャパンの羽生章洋が書いてるブログ:営業と要件定義 - livedoor Blog（ブログ）
そういう不可欠の職種である営業ですが、良い印象を与えないことがある理由は何かというと、無理矢理押し込むという風に思われているからではないかと感じます。要するに押し売りなのではないかと。あるいはyes but法などに代表されるような、ああいえばこういう的に言葉巧みに相手を追い込んでいくというような、駆け引きで買わせるという風に思われていることもあるかもしれません。 しかし私どものような業務システムの受託開発のように、既に存在する商品を売るのではない、所謂ソリューション営業あるいはコンサルティング営業の場合には、この押し込み型の営業というのは、実はなかなかに厳しいものがあります。 SI業界でも押し込み型の営業スタイルで成功体験を築き上げてきた方々はいます。ただその場合は、よくよく見るとシステムというよりもやはりハードウェアありきだったと見受けられることが多いのです。 受託開発の営業というのは、
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
そろそろ例のプロジェクトについて言及するか - 西尾泰和のはてなダイアリー
以前、とあるシステムのソースコードを読む機会があったのだけどあまりにひどかった。あのひどいコードでまあまあまともに動いているというのが逆に信じられない。今日昼ご飯を食べながら少し話していたのだけど意外と知られていないようなので、話せる範囲でいかにひどいのか説明してみようと思う。 まず、ソースコードが大雑把に見積もって3750万行あるのだけど、その中でまともに機能しているコードは3%しかない。10分の1程度のソースコードで同程度の機能を実現しているシステムもあるのでほんとあのシステムのコードはゴミだと言っても過言じゃない(*1) プログラマとしてはなんでそのプロジェクトはそんな状態になってしまったのか気になるところだけども、まあ多くのプロジェクト同様、真相を知る人は誰もいない。でもまあ、実際に機能しているコードのコピーみたいなものがあちこちに散らばっていることからしてコピー＆ペーストが盛んに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
