お気軽にお問い合わせください。0967-73-1111受付時間 9:00-18:00 [ 土・日・祝日除く ] お問い合わせ
株式会社ソフトビル
お気軽にお問い合わせください。0967-73-1111受付時間 9:00-18:00 [ 土・日・祝日除く ] お問い合わせ
JPAを使ったデータアクセスでポイントとなる永続コンテキストについて - 達人プログラマーを目指して
先週書いたエントリJava EE6標準の範囲でフルスタックのWebアプリケーションが簡単に作成できることを確かめてみました。 - 達人プログラマーを目指してで、Java EE6の標準仕様を使うだけで、かなりシンプルにデータのCRUD処理を行うアプリケーションが作成できることを紹介しました。ただし、前回は全体のアプリケーションを紹介しただけなので、細かい仕掛けについては解説しきれませんでした。今回は、前回に引き続き特にJPAを使ったデータベースアクセスの部分がどうなっているのかをもう少し掘り下げて解説してみたいと思います。 なお、この場で宣伝ですが、8月10日（水）にGlassfishユーザーグループの勉強会にてお話をさせていただくことになりました。 GlassFish Japan Users Group 勉強会 2011 Summer : ATND 私はJava EE6を使った開発について
京都市：市場施設管理システムの更改に関する情報提供について（依頼）
京都市中央卸売市場第一市場では，平成28年度から始まる施設整備にあわせて「市場施設管理システム」の更改を検討しています。 つきましては，新システムを構築する際の参考資料として活用するため，下記のとおり，情報提供を依頼します。
株式会社カルミナ
皆様へ 弊社は諸般の事情により、このたび事業を休眠いたします。今後の再開の予定はございません。 弊社との過去の契約や納品物に関連するお問い合わせについては、引き続き下記のお問い合わせフォームまでお気軽にご連絡いただけますようお願い申し上げます。 長い間ご愛顧をいただき、心から感謝申し上げます。 皆様には今後とも益々のご健康とご成功をお祈り申し上げます。 弊社の休眠に際し、ご不便、ご迷惑をおかけすることと存じますが、何卒ご理解賜りますようお願い申し上げます。 株式会社カルミナ 代表取締役社長 安藤昭太
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
YAYOI SMART CONNECT｜会計ソフトなら弥生株式会社【公式】
口座自動連携ツール データ連携できる金融機関は、全国1,100件以上。連携可能な金融機関のサービスは2,500件以上（2023年7月時点） ※クラウド版（Microsoft Windows、macOS対応）、インストール版（Microsoft Windows専用）で対応金融機関が違います。 対応金融機関一覧 CSVファイル取込 全銀協フォーマット、三井住友・三菱UFJ・横浜・りそなの各銀行、および「しんきん法人向けインターネットバンキング（PDF）」のフォーマットに対応。 また、取り込みの設定を行うことにより、任意の形式のCSVファイルを取り込むことができます。 銀行口座管理 銀行口座管理 見積・請求サービス 見積・請求サービス POSレジ POSレジ POSレジ POSレジ POSレジ 画像取込サービス 画像取込アプリ Eコマース ネットショップ 開設サービス インボイス管理 サービス
flint blog: 履歴を取ってみよう
けれども、この「更新日時」が実用にどれほど役に立つものかを考えてみると、その効果のほどは甚だ疑問です。 何故なら、このフィールドはあくまで「最終の」更新日時を表すものに過ぎず、次の更新が生じたときに、その値は上書きされてしまうもの。 その最終の更新についてさえ、「いつ」行われたかは分かるものの、「どのような」変更がなされたかについては、何の情報も提供されません。 そうしたことを考えると、この「更新日時」のフィールドは殆ど意味を持たないものだと言えます。 話は変わりますが、Mac OS においてはファイルへのアクセス日時が最終のものだけでなくすべてが記録される模様。 これは便利と言えば便利なのかもしれませんが、恐ろしい気もしますね。 閑話休題。 こうした事情から、より重要なデータを扱うシステムでは任意の時点におけるレコードの状態を参照できるようにするため「履歴」の情報を含めてデータベースに格
flint blog: でかいテーブルの恐怖
あけましておめでとうございます。 1月も既に半ばではありますが。 昨年10月の下旬から始まった仕事のスケジュールがこれまでと較べてかなりタイトなもので、ブログの更新もすっかり滞っておりました。 今回の仕事を含め、大学時代から、何故か他人が作ったシステムの分析・改修を手掛けることが多いのですが、それらの中には動作しているのが不思議なほどに設計・実装がグダグダなものが少なくありません。 特に、データベースを利用するような比較的規模の大きなシステムにおいては、そうした出来の悪さは「手の施しようのない」悲惨な稼動状態 (加えて、にも関わらずなんとかしなければならない凄惨な作戦状況) を生み出すことに。 このエントリでは、その要因の一つである巨大な (カラム数の多い) テーブルについて述べていくことにします。 テーブル定義が肥大化する要因を個別に検討する前に、私のおおまかな判断基準を示すと、 カラム
エラーページ - 産経ニュース
ページが存在しません 指定されたURLは存在しませんでした。 5秒後に産経ニューストップページへ移動します。 産経ニューストップへ
特許庁がシステム刷新に再挑戦、足かけ8年の巨大プロジェクトをスタート
一度は失敗したシステム刷新に、特許庁が再挑戦する。2015年3月までに新システムのアーキテクチャー案や移行計画をまとめた上で、3月末か4月から同案の妥当性について意見を募集（図）。集めた意見を基に計画を修正し、要件定義と調達活動を開始する予定だ。 要件定義や調達手続きに1年以上かかるため、新アーキテクチャーに基づくシステム開発が始まるのは2017年頃、刷新完了は2022年頃となる。「次の失敗はない」（特許庁）。同庁は、不退転の覚悟でシステム刷新に臨む。 過去の失敗から5つの反省 特許庁は基幹系システムの全面刷新を2006年に始め、設計・開発業務を東芝ソリューション、管理支援業務をアクセンチュアがそれぞれ落札した。だが開発は難航し、5年後の2012年1月に開発中止に追い込まれた（関連記事1：55億円無駄に、特許庁の失敗、関連記事2：2012年の特許庁システム開発中止、開発費全額返納のなぜ）。
システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国 - プロマネブログ
う～ん、まあ、相変わらずツッコミドコロがいっぱいあるのだけど、一番肝心なところだけ。 総務省の情報システム調達ガイドラインを読んでないよな もちろん、政府もこうしたことに深刻な問題意識を持っており、民間から政府CIOを起用し、そのスタッフも充実させるなど更なる改革に取り組んでいる。2015年4月からはシステム調達に関する新たなガイドラインも施行する。 (中略) だが、あくまでも「この通りに実施できれば」の話だ。ガイドラインでは、システムを導入する際には利用部門の業務改革を行うことを義務付けている。全く正しいが、この手の業務改革は民間企業で軒並み失敗しており、ハードルはさらに高くなる。業務やITに精通するだけではダメで、ベンダーマネジメントや、利用部門を統制する“ユーザー”マネジメントなどをこなせるIT人材が必要だ。 (中略) そして地方自治体や外郭団体に至っては、その多くがいまだに丸投げ＆
巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話
最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。銀行システムをSOAで構築するのは日本では初めて！！すごい！！先進的！！！という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので本当に謎
逆転の発想で1割を9割の成果にした信用組合のセキュリティ強化策
2014年は情報セキュリティに取り組む企業での残念な点ばかりを指摘してきたが、最後はすばらしい成果を達成した企業でのケースを紹介したい。 読者の皆さんは、金融機関のセキュリティがその他の業種に比べて極めて強固だと思われているのではないだろうか。しかし、実態は違う。同じ従業員規模でみれば金融機関のセキュリティは、“多少はマシ”というレベルが多く、中には「零細企業レベル」というところすらある。本連載ではこんな辛口ばかりを掲載してきた。せめて2014年の最後は、筆者が情報セキュリティの相談に対応する中で良かったことをお伝えし、1年を締めくくりたい。 専門家を生かす企業 さて筆者は、2013年から2014年10月にかけてA信用組合で情報セキュリティを強化する作業にあたった。無事予定通りに完了したケースだ。最初の段階で筆者がどう行動すべきか尋ねたところ、役員から「今まで萩原氏のセミナーや講演を何回も
レガシーコード改善勉強会 開催レポート
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27（土）の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード（テストコードが無いコード）と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 ＜開催趣旨・目的＞ テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、
モダンなチーム開発環境を整える | サーバントワークス株式会社
モダンなチーム開発環境 モダンなチーム開発環境の考慮ポイントの図解 ソフトウェア開発は、ビジネス価値を創造する一翼を担っていますので、ビジネスアイデアをビジネス価値に転換するビジネスパーソンの意向は、とても大切です。それを「動くソフトウェア」にするために、開発エンジニアリングを行うわけですが、それがとても複雑であるということです。ウォーターフォールモデルで開発できる場合は、工程ごとにガッツリ全体を作っていくのである意味シンプルに見えます。しかし、それらの成果の関連や追跡可能性を考えてみるとウォーターフォールモデルで追跡可能性を創出し、維持することはとても難しいことはわかってきます。では、アジャイルな開発、優先順位を決めて、提供可能なものを選んで開発し、提供し続けるモデルの場合は、企画ー計画ー開発ービルドーデプロイが何度も繰り返されるだけではなく、パラレルに動くことが要求されます。たとえば、
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
Modern Java Web / SPA Development
JJUG CCC 2014 Spring の発表資料です。
なぜITベンダーは「できもしない低料金」で仕事を受注するのか | スラド
日経ITproにて、とあるシステム納入にまつわる「複数のITベンダーの営業担当者やユーザー企業のシステム部長らから聞いた話を基に組み立てたストーリー」が取り上げられている（ベンダーとIT部門がぶち切れた“仕打ち”の理由）。 とあるベンダーが企業にシステムを提案したところ、途中でその案件に対し他社とのコンペが行われることになり、その結果あり得ない低料金で他社にその案件を持って行かれた、という話が取り上げられている。その後受注したベンダーは予算通りでは納品ができず大火事に、発注側も金額オーバーと納期オーバーでダメージを受けた、というシナリオだ。 この記事では、コンペになったのは発注側の調達部門がコンプライアンスを理由として押し通したからとされているが、それよりも問題なのは「あり得ない低料金」を提示したベンダーだろう。この「シナリオ」では「受注したベンダーはSCM関連の実績はない」という設定だが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバー管理会社の家宅捜査について
不用品回収センター -