日本マイクロソフト、GitHub上でクラウドPOSなどのソースコードを公開
日本マイクロソフト、GitHub上でクラウドPOSなどのソースコードを公開：スマートストア構築支援に向けた取り組みの一環 日本マイクロソフトは2019年1月29日、日本独自の取り組みとして、小売業が「スマートストア」構築に使えるキャッシュレス／スマートフォン決済対応POSや、商品マスター／在庫管理システムのソースコードを、GitHub上で公開すると発表した。 日本マイクロソフトは2019年1月29日、小売業が「スマートストア」構築に使えるキャッシュレス／スマートフォン決済対応POSや、商品マスター／在庫管理システムのソースコードを、GitHub上で公開、誰でも無償で活用できるようにすると発表した。当然ながら、これらのコードはMicrosoft Azure上での稼働を前提としている。 日本マイクロソフトが1月29日に行った説明によると、同社は日本独自の取り組みとして、小売業のスマートストア化
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
基本/詳細設計って呼び方やめませんか - Qiita
システムエンジニア Advent Calendar 2016 の 15 日目です。システムエンジニアなら避けては通れない設計について考えたことを書いてみようと思います。 設計ってむずかしい システム開発の様々な局面で「設計ってむずかしいなあ」と思うことがあります。細かいところはシステムの規模や自分のポジションによって変わりますが、だいたい以下に挙げたようなことで困ることが多いです。 設計 なにを、どこまで、どんなフォーマットで書くといいんだろう？ 各ドキュメントはどうやって関連付けるといいんだろう？ 基本設計書と詳細設計書はなにが違う？ 開発 なんでこういう設計になっているんだろう？ 設計されていない組み合わせのデータはどう処理すればいいんだろう？ 試験 試験データのパターンや量はどれくらい用意すればいいんだろう？ 運用 設計と実装が乖離していてなにが正しいのか分からない... 仕様変更や
177bdf6352de463fdc87
経験ゼロでもできるプログラミング現場の単体テストを読んだので、そのまとめ はじめに 著者曰く、 初めて導入する単体テストの指南書 を目指した一冊。 単体テストを書いたことが無かったり、書いたことがあっても書き方の方針が定まっていない人にはおすすめの本。 逆に既にバリバリテストコードを書いてる人に、再確認的な内容になるかも。 単体テストについて基礎知識 アプリケーション開発では設計に時間がかかりすぎて、テストに時間をかけられないことがある。 致命的な障害発生する可能性がある。 とはいえすべてを想定してテストを実施することはできない。 テストケースを絞る必要がある 各テストフェーズの礎となる単体テストが重要になる 高品質なシステム ユーザーを満足させ、不安や不満をいだかせないこと システムエラー：データの破損などの心配が生まれる 応答が遅い：いらいら・二度と使わなくなる まとめてテストはダメ
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
プログラミングの楽しさ。オープンソースとの出会い。 - 2nd life (移転しました)
100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊 が出版され、『私と Ruby と添削と』という内容で寄稿しました。私がどうプログラミング・オープンソースの楽しさを知ったかについての昔話です。公開して良い、とのことなので公開いたします。 なお、文章中に出てくる tdiarytimes.rb のコードは以下です。9年前に書いたコードなので今読み返すと恥ずかしいを通り越してもはや微笑ましいですね！！１これでも当時は、自分なりにできるだけ綺麗なコードにして公開した記憶があります。 https://github.com/tdiary/tdiary-contrib/blob/master/plugin/tdiarytimes.rb 私と Ruby と添削と プログラミング技術の向上させるには、どういう方法があるでしょうか。プログラミングに関する書籍を読む、オープンソースで公開されて
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
