テクマトリックス、C#/VB.NET対応静的解析・動的解析ツールの最新版「dotTEST 2020.2」を販売開始
Docker社、Docker Hubのソースコードの一部を「Docker Distribution」としてCloud Native Computing Foundationに寄贈
Docker社、Docker Hubのソースコードの一部を「Docker Distribution」としてCloud Native Computing Foundationに寄贈 Docker社は、同社が提供しているDockerコンテナのレジストリサービス「Docker Hub」のソースコードの一部であり、さまざまなDockerコンテナレジストリサービスのリファレンス実装にもなっている「Docker Distribution」を、Cloud Native Computing Foundationに寄贈したことを発表しました。 Docker HubはDockerコンテナのイメージを登録し、検索し、引き出すことのできるレジストリサービスです。 こうした、いわゆるDockerコンテナレジストリのサービスは、現在ではDocker社以外にもさまざまなクラウドベンダやソフトウェアベンダが提供しています
6割超のエンジニア、現在の開発プロセスに「課題あり」、大規模開発にはアジャイル型を求める声
調査対象者に、勤務先でおもにどのような開発プロセスを採用しているかを尋ねたところ、「ウォーターフォール型」が58.2％、「アジャイル型」が12.1％となった。 いずれかの開発プロセスに携わっていると回答した人に、開発プロセスに課題を感じたことがあるかを尋ねた質問では、66.3％が「感じたことがある」と答えている。 開発プロセスに課題を感じたことがあると回答した人に、具体的な課題の内容を尋ねたところ（複数回答）、「見積もった工程と実績に乖離がある」（75.5％）がもっとも多く、以下「仕様工程による手戻りが多い」（67.9％）、「テスト工程が削減できない」（30.2％）が続いた。 その他の課題としては、「スロースタートになりやすく、慢性的な遅延が発生する」「手戻りが多く、開発コストがかさむ」といった回答が寄せられている。 開発プロセスに課題を感じたことがあると回答した人に、勤務先が採用している
GitHub上のソースコード流出問題の被害は5社に、NECとコアも確認
米GitHub（ギットハブ）が運営するソフト開発プラットフォーム「GitHub」上へのソースコード流出問題が広がっている。NECと中堅ITベンダーのコアが、自社が開発に携わったシステムに関して一部ソースコードの流出を確認したことが2021年2月2日までに分かった。既に流出を確認した三井住友銀行（SMBC）やNTTデータ子会社のNTTデータ ジェトロニクス、サイオス子会社のProfit Cubeを含め、被害企業は5社に拡大した。 NECは、GitHubに無断で投稿された一部のコードが「ある顧客向けに開発した業務システムの一部であると確認した」（広報）。納入先の顧客はデータ流出やセキュリティー上の悪影響がないことを確認できているという。NECグループ社員がソースコード流出に関与していないことも確認できており、NECの委託先企業の社員による可能性を含めて流出経路について調査を進めている。 コアも
CloudLinux、「CentOS」の代替OS「AlmaLinux」ベータ版リリース
「CentOS Linux」プロジェクトの実質的なオーナーであるRed Hatが、「Red Hat Enterprise Linux」（RHEL）のリビルド版であるCent OSから、最新版のRHELの少し先を行く「CentOS Stream」に重心を移すという発表を行ったとき、多くのCentOSユーザーは憤慨した。この事態を受けて、以前から自社の名前を冠したマルチテナント型のウェブ／サーバーホスティング企業向けのRHELなどをベースにしたLinuxディストリビューションを作っているCloudLinuxは、新たなCentOSクローンである「AlmaLinux」を立ち上げると発表していた。このほど、このAlmaLinuxのベータ版が公開された。 Red Hatは、「Red Hat Developerプログラム」を拡大し、開発者や小規模なチームが利用できる無料版のRHELを新しく発表しているが
Microsoft、C#やRustからWin32 APIへのアクセスを容易にする計画を発表
Win32 APIをアプリケーションから利用すると、Windowsを最大限に活用できる。CやC++の開発者であれば既存の仕組みを容易に利用できるものの、C#やRustのような言語からWin32 APIへアクセスするには、手動でAPIのラッパーやバインディングを作成する必要がある。この方法はエラーが起こりやすく、広範なAPIをカバーする拡張性にも欠けている。 近年では、さまざまな言語からWin32 APIを呼び出す必要性が高まっている。これを背景として、ラッパーやバインディングで強く型付けされた慣用的な表現を提供し、開発者の負担を軽減する幾つかのコミュニティープロジェクトも登場している。.NET向けの「P/Invoke」や、Rust向けの「winapi-rs」などが有名だ。 これらのプロジェクトは有望なものの、手動でメンテナンスされているため、広範なAPIを持続的にカバーするのは困難であり、
2020年12月のWindows Updateでまたまた不穏な挙動！ 油断ならない「更新プログラムのチェック」ボタンに注意
山市良のうぃんどうず日記 2020年最後の定例更新で遭遇したさまざまな挙動 筆者はさまざまなバージョンのWindowsを仮想マシン環境に維持しており、米国時間の第2火曜日に提供される「定例更新（Bリリース）」は必ずインストールしています。オプションの更新プログラム（更新プログラムのプレビュー、Cリリース）は、「Windows Update」の動作確認のためにインストールすることもありますが、仮想マシンのスナップショットでロールバックしてBリリースの更新状態にしています。 2020年12月の最後のWindows Updateでは、Windowsのバージョンや設定によって、いつもとは少し異なる幾つかの挙動のパターンに遭遇しました。それを踏まえて、2020年12月に皆さんが遭遇したかもしれないWindows Updateのおかしな挙動を以下にリストアップしてみました（これら以外のパターンもあるか
Modern Best Practices for Testing in Java
Philipp Hauer's Blog Engineering Management, Java Ecosystem, Kotlin, Sociology of Software Development Posted on Sep 9, 2019. Updated on Dec 18, 2022 Maintainable and readable test code is crucial to establish a good test coverage which in turn enables implementing new features and performing refactorings without the fear of breaking something. This post contains many best practices that I collect
平均的プログラマ以前向けのスキルの指標 - Lazy Diary @ Hatena Blog
「Java経験年数〇年以上のプログラマ募集」みたいなフレーズ、よく聞きますよね*1。求めるスキルを示すのに「〇〇言語でプログラミングができること」あるいは「〇〇言語経験年数〇年以上」という表現を使うことはよくあるようです。ですが、このレベルの記述では粒度が荒すぎて、求めるレベルとのスキルアンマッチが容易に発生しそうです。 この問題は、客観的に評価できるスキル標準を利用することで解決できそうです。コンピュータソフトウェアエンジニアのスキルレベルを示す指標としては、ISO/IEC 24773*2・英国SFIA*3・IFIP IP3*4、国内ではIPAのITスキル標準モデル*5や情報処理学会のCITP制度*6などがあります。しかしこれらの指標は、スキルレベルを示すと同時に、目指すべきスキルのモデルケースを示すものでもあります。したがって、これらの指標はエンジニアの平均的なレベルよりも高い水準に設
平均的プログラマ以前のメンバーにどう対処していけばよいか？ (1/2) - Lazy Diary @ Hatena Blog
https://note.mu/kotofurumiya/n/n31d401fce782note.mu 非常によい知見というか、経験談の集まりで、共感するところも多く、興味深く読んだ。大学のプログラミング実習の話のようだけど、企業においても、新卒採用で情報系以外の学科から採用をしている場合、状況はあまり変わらない。 以下、上記記事から面白いと思ったポイントをとりあげて、下記の指標でいったらどのくらいのレベルなのか？を考えていきたい。 satob.hatenablog.com どこまで進んだかな......?えっまだそこ?進んでなくない? ときどき見かける。指標でいうとレベル1～4くらい（スキルミスマッチがかなり大きい状態）と思われる。 ただ「作業が進まない」という事象はプログラミングに限った話ではなく、作業者のレベルによっては一般的な事務作業でも発生する。 たとえば「Excelのこのファイ
O'Reilly Japan - Library
オライリー・ジャパンでは、これまで多くの書籍を発行してきました。その中には、オープンなライセンスの下で公開されているものがいくつか存在します。 下記に、オープンなライセンスで出版されている書籍へのリンクをまとめます。それぞれの書籍のライセンス等についてはそれぞれのリンク先をご参照ください。 GNU Make 第3版 オープンソースソフトウェアの育て方 オープンソースソフトウェア Feedback 皆さんのご意見をお聞かせください。ご購入いただいた書籍やオライリー・ジャパンへのご感想やご意見、ご提案などをお聞かせください。より良い書籍づくりやサービス改良のための参考にさせていただきます。 [feedbackページへ]
Microsoft .NET Framework 修復ツールを使用できます - Microsoft サポート
.NET Framework 4.8 .NET Framework 4.7.2 .NET Framework 4.7.1 .NET Framework 4.7 .NET Framework 4.6 .NET Framework 4.6.1 .NET Framework 4.6.2 .NET Framework 4.5.2 .NET Framework 3.5 Service Pack 1 はじめに Microsoft .NET Framework 修復ツールは、Microsoft .NET Framework のセットアップまたは更新に影響を与える頻繁に発生する問題を検出します。 ツールは、既知の修正プログラムを適用するか、サポートされている .NET Framework バージョンの破損したインストールを修復することで、これらの問題を解決しようとします。 このツールには、使いやすいウィザ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
汎用暗号化ライブラリLibgcryptに緊急のセキュリティ脆弱性、すぐにアップデートを
GitHubで公開されたソースコードを巡回監視、指定キーワードで通知 メタエクスが3月提供スタート（ITmedia NEWS） - Yahoo!ニュース
さよならPHP、WindowsでのPHPのサポートが「2022年11月28日」に完全終了
Seamlessly Accelerate CMake Projects in Visual Studio with Incredibuild - C++ Team Blog
C#やRustからWin32 APIをもっと簡単に呼び出せるように ～Microsoftが「win32metadata」プロジェクトを発表／今まで手動でメンテナンスされてきたバインディングやラッパーを自動管理する基盤
Publish Web Application with Multiple Projects
C++/CLI の例外
C++CLI入門/中間言語とネイティブコードの混在 - WisdomSoft