山市良のうぃんどうず日記 2020年最後の定例更新で遭遇したさまざまな挙動 筆者はさまざまなバージョンのWindowsを仮想マシン環境に維持しており、米国時間の第2火曜日に提供される「定例更新(Bリリース)」は必ずインストールしています。オプションの更新プログラム(更新プログラムのプレビュー、Cリリース)は、「Windows Update」の動作確認のためにインストールすることもありますが、仮想マシンのスナップショットでロールバックしてBリリースの更新状態にしています。 2020年12月の最後のWindows Updateでは、Windowsのバージョンや設定によって、いつもとは少し異なる幾つかの挙動のパターンに遭遇しました。それを踏まえて、2020年12月に皆さんが遭遇したかもしれないWindows Updateのおかしな挙動を以下にリストアップしてみました(これら以外のパターンもあるか
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
C++/CLIによるコンパイルは、純粋な .NET Framework マネージコードだけではなく、マシン語で書かれたアンマネージコードとの混在が可能です。当然、アンマネージコードを混在させるか、純粋なマネージコードのみを許可するかを選択することもできます。 .NET Framework 対応アプリケーションを開発するということは、共通中間言語を含む実行ファイルを生成するということです。従来の C++ コンパイラは、コンパイラが対象とするプラットフォームのマシン語で構成される実行可能ファイルを生成しましたが、Visual C++ のプロジェクトでは .NET Framework 専用のアプリケーションを開発することができます。これは、すなわち共通中間言語を含む実行ファイルが出力されるということです。 C++ 言語は、.NET Framework 専用に設計された C# や Visual B
「Java経験年数〇年以上のプログラマ募集」みたいなフレーズ、よく聞きますよね*1。求めるスキルを示すのに「〇〇言語でプログラミングができること」あるいは「〇〇言語経験年数〇年以上」という表現を使うことはよくあるようです。ですが、このレベルの記述では粒度が荒すぎて、求めるレベルとのスキルアンマッチが容易に発生しそうです。 この問題は、客観的に評価できるスキル標準を利用することで解決できそうです。コンピュータソフトウェアエンジニアのスキルレベルを示す指標としては、ISO/IEC 24773*2・英国SFIA*3・IFIP IP3*4、国内ではIPAのITスキル標準モデル*5や情報処理学会のCITP制度*6などがあります。しかしこれらの指標は、スキルレベルを示すと同時に、目指すべきスキルのモデルケースを示すものでもあります。したがって、これらの指標はエンジニアの平均的なレベルよりも高い水準に設
https://note.mu/kotofurumiya/n/n31d401fce782note.mu 非常によい知見というか、経験談の集まりで、共感するところも多く、興味深く読んだ。大学のプログラミング実習の話のようだけど、企業においても、新卒採用で情報系以外の学科から採用をしている場合、状況はあまり変わらない。 以下、上記記事から面白いと思ったポイントをとりあげて、下記の指標でいったらどのくらいのレベルなのか?を考えていきたい。 satob.hatenablog.com どこまで進んだかな......?えっまだそこ?進んでなくない? ときどき見かける。指標でいうとレベル1~4くらい(スキルミスマッチがかなり大きい状態)と思われる。 ただ「作業が進まない」という事象はプログラミングに限った話ではなく、作業者のレベルによっては一般的な事務作業でも発生する。 たとえば「Excelのこのファイ
オライリー・ジャパンでは、これまで多くの書籍を発行してきました。その中には、オープンなライセンスの下で公開されているものがいくつか存在します。 下記に、オープンなライセンスで出版されている書籍へのリンクをまとめます。それぞれの書籍のライセンス等についてはそれぞれのリンク先をご参照ください。 GNU Make 第3版 オープンソースソフトウェアの育て方 オープンソースソフトウェア Feedback 皆さんのご意見をお聞かせください。ご購入いただいた書籍やオライリー・ジャパンへのご感想やご意見、ご提案などをお聞かせください。より良い書籍づくりやサービス改良のための参考にさせていただきます。 [feedbackページへ]
.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 バージョンの破損したインストールを修復することで、これらの問題を解決しようとします。 このツールには、使いやすいウィザ
.NET Framework アプリケーションを実行しようとすると、"このアプリケーションを起動できませんでした" というエラー メッセージが表示されることがあります。 このエラーは、インストールされているバージョンの .NET Framework が検出されないか、.NET Framework が破損していることが原因で発生した場合は、この記事を使用してその問題を解決してください。 この記事のすべての手順を完了してもアプリケーションを実行できない場合は、ファイル システムの破損、依存関係の不足、アプリケーションの問題など、何らかの理由で問題が発生している可能性があります。 その場合は、アプリの発行元に問い合わせるか、 Microsoft サポート コミュニティ または Microsoft Q&A に質問を投稿してヘルプを受けることができます。 エラーの修正方法 アプリケーションを実行でき
この記事は新野淳一氏のブログ「Publickey」に掲載された「個人開発者はRed Hat Enterprise Linuxを無料で最大16システムまで利用可能に、本番環境もOK。Red Hatが開発者向けプログラムの拡大を発表」(2021年1月22日掲載)を、ITmedia NEWS編集部で一部編集し、転載したものです。 米Red Hatはこのほど、個人開発者向けに提供している「Red Hat Developerプログラム」を拡大し、個人開発者には無料で最大で16システムまで本番環境でも利用可能にすることを発表しました。 これは先月発表された、CentOS 8のサポートを2021年末までとし、今後はCentOS Streamの開発に注力することへの影響を考慮したもの。 無料で本番環境を含む最大16システムまで利用可能 現在のRed Hat Developerプログラムは個人開発者に対して
Kevlin Henney(編)、和田卓人(監修)『プログラマが知るべき97のこと』(オライリー・ジャパン、2010年)を出典とする。各エッセイはCC-by-3.0-USによってライセンスされている。 どんなに余裕あるように見えたスケジュールでも、実際に作業を始めれば、必ずどこかで追い詰められた状態になるものです。そして、同じことを「正しくやる方法」と「手早くやる方法」があれば、後者の方が魅力的に見えてしまうことはよくあります。後者を選べば、後で修正が必要になるとわかっていても、その時は「必ず、すぐに修正しよう」と自分に誓うでしょう。プロジェクトチームのメンバーや、顧客などに修正を約束することもあります。約束した時点ではもちろん、絶対に約束を守るつもりでいます。次のイテレーションなどが修正のチャンスなのですが、実際にイテレーションが始まると、また新たな問題が起きてそちらに注力してしまい、結
この記事には複数の問題があります。 改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。(2024年2月) 独自研究が含まれているおそれがあります。(2024年2月) 出典検索?: "DLL地獄" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL DLL 地獄(ディーエルエルじごく)とは、DLL や COM コンポーネントなどのバージョンアップなどに伴い、それ以前のバージョンの DLL/COM コンポーネントなどに依存して動作するアプリケーションが動作しなくなる現象のことである。コンピュータ業界においては "DLL HELL" と呼ばれる場合が多い。Windows 以外の オペレーティングシステム (OS) で発生するものについては
某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー
IT技術者のSacha Greif氏とRaphaël Benitte氏が、JavaScriptに興味を持つ世界中のIT技術者約2万4000人にアンケートを取り、結果をまとめたWebサイト「State of JavaScript 2020」が公開されています。 JavaScriptの最新のシンタックスや命令がどれくらい使われているか、フロントエンドやバックエンド、ビルドツールなど分野ごとにさまざまなJavaScript関連の技術はどれくらい興味を持たれているかなど、アンケート結果を基にして、満足度(Satisfaction)、興味(Interest)、利用率(Usage)、認知度(Awareness)などを計算。それぞれについてランキングを作成しています。 それぞれの値は次の式で計算されると説明されています。それぞれの項目にはアンケートの回答数が入ります。 満足度=またこの技術を使いたい/(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く