パスワードを忘れた? アカウント作成

最新から新しい日記やタレこみを確認できますよ。

2021年のデベロッパー人気記事トップ10
15285583 story
プログラミング

MicrosoftのC#コーディング規約に「privateフィールドにはプレフィックス」と追記されて混乱を呼ぶ 129

ストーリー by headless
混乱 部門より
あるAnonymous Coward 曰く、

C#のコーディング規約として一番権威あるのは本家Microsoftのものだと思われるが、そのページに、いつの間にか「private/internalフィールドには _ プレフィックス」「private/internalなstaticフィールドには s_ プレフィックス」「ThreadStaticの場合は t_ プレフィックス」を付ける必要がある(should)という項目が追加され、C#er達が大混乱に陥っている(C#のコーディング規則発端となったツイート)。

C#においては、後発のUnityがプレフィックスを付ける文化を持っている一方、本家のC#においては、プレフィックスを付けずに this. で参照する文化があり、StyleCop.Analyzersなどのスタイルチェックもこれをデフォルトとしている。また、2010年頃のプログラミング書籍では「メンバー変数にプレフィックスを付けるのはIDEが未発達の頃の名残で、IDEが発達した現代では不要」としてプレフィックスを付けないことが推奨されていたと記憶している。

今回の記述はそうしたこれまでの流れと真っ向から対立するもので、Twitter上ではアンダースコア派が歓喜する一方、this派からは大ブーイングが起こっているようだ。ただし、この規約が書かれたのは6年前でそれが今になって反映されただけといったコメントもあるなど、なんでこうなったかはよく分からない。

元となったコーディング規約はオープンソースの.NETランタイム貢献者向けに書かれたものであり、C#開発者一般に向けたものではない。日本語版にはまだ反映されていないが、英語版には「.NET Runtime, C# Coding Style」から取り入れられたものであることが明記され、使いたければ使えばいいという感じになっている。「s_」「t_」の使用はハンガリアン記法を使用しないよう求める.NETの一般的な名前付け規則に反するが、この点は解決されていない。

なお、元のコーディング規約では「this.」について、「どうしても必要な場合を除いて避ける」と記載されている。

15167970 story
Android

Huaweiの「独自OS」は結局Androidのフォークなのか 88

ストーリー by nagazou
すぐにOSなんて作れないし 部門より
headless 曰く、

Ars TechnicaのRon Amadeo氏によれば、Huaweiの「独自OS」HarmonyOS 2.0のベータ版はAndroidのフォークにしか見えないそうだ(Ars Technicaの記事The Vergeの記事)。

Huaweiは最悪の事態に備えて2012年から独自OSを開発しており、IoTデバイス用のOSとして使用していたが、最悪の事態が現実化してAndroid OSを使用できなくなったことからスマートフォンにも投入する計画を示している。HarmonyOSについてHuaweiの王成録氏は先月、Androidのコピーでもなく、iOSのコピーでもないと述べていた。

HarmonyOS 2.0のユーザーインターフェイスはHuaweiのAndroidデバイスと同じEMUIを使用するため、外見が似ているのは当然といえば当然だが、HuaweiのアプリストアApp Galleryで入手可能なシステム情報アプリを実行すると、「Android 10 Q」と表示されるという。また、設定アプリでインストール済みアプリのリストを表示すると、Androidのパッケージがいくつも表示されるようだ。さらに「HarmonyOS System」というパッケージのバージョンは「2」ではなく「10」になっている。

HuaweiはHarmonyOSを「OpenHarmony」としてオープンソース化する計画を示しており、既にIoT向けバージョンはソースコードが公開されているが、こちらはHarmonyOS 1.0ベースであり、HarmonyOS 2.0とは明らかに異なるようだ。スマートフォン向けのバージョンは4月以降の公開となるため、現在のところソースコードを照合してフォークかどうかを確認することはできない。ただし、Amadeo氏が実行してみた限りAndroidと明らかに異なる点は見当たらないとのこと。ベータ版のOSにしては完成度が高過ぎるとも指摘している。

HuaweiがAndroid Open Source Project(AOSP)をフォークして独自OSを開発することに問題はないものの、Huaweiはフォークしたとは言っていない。HarmonyOS開発者サイトのドキュメントを検索しても「Android」を含むページはヒットしない。ただし、Google検索により、AOSPに言及するオープンソースライセンス関連ドキュメント2件見つかった

なお、SDK入手には登録が必要であり、写真入り身分証明書やクレジットカード表面のスキャンをアップロードするなどしたうえで、2日間の確認待ちが入るという大掛かりなものとのことだ。

15412232 story
OS

Linus Torvalds氏、「GitHubが生成するマージは使い物にならない」と語る 47

ストーリー by nagazou
ダメ絶対 部門より
Linuxディストリビューション5.15では、Linus Torvalds氏がLinuxカーネルにParagon Software製のNTFS3カーネルドライバーを導入を認め、WindowsのNTFSファイルシステムをサポートするためのNTFS3カーネルドライバーが導入されることとなった。新たなドライバーは現在利用可能なNTFSドライバーと比較して機能およびパフォーマンスにおいて優れているとされる(Linus Torvalds氏のコメントThe RegisterPhoronixMarket Research TelecastZDNet Japan)。

Torvalds氏は8月にNTFS3カーネルドライバーの統合許可を行い、Paragon Softwareに対し、「とにかくGitのpullリクエスト出してほしい」と伝えていたそうだ。対してParagon Softwareは3日にプルリクエストを送ったと回答していたものの、それはTorvalds氏の意向に反し、GitHubのウェブインターフェースから送信されたものだったとのこと。

Torvalds氏は、将来のプルリクエストを改善するため、Paragon SoftwareのKomarov氏にいくつかの注意を行っている。一つはGitHubのウェブインターフェースからLinuxカーネルにコードをマージするのは「絶対に」避けるべきだとするもの。

曰く、GitHubが生成するマージは全く使い物にならない。Linuxカーネルのマージは「適切に」行う必要があるが、マージに関連する情報を含む適切なコミットメッセージが必要だ。しかし、GitHubのマージはすべてを台無しにすると話している。ほかにも、GitHubのアカウントを使用する場合、プルリクエストにブランチだけでなく署名付きタグを付けてほしいなどに関しても指摘している(Linus Torvalds氏のコメントその2)。
15160405 story
プログラミング

「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない?」という海外の分析 260

ストーリー by nagazou
なんででしょう 部門より
あるAnonymous Coward 曰く、

元ネタが投稿されたのは1年ほど前のようだが、「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない?」(Why doesn’t Japan excel in software as they did in hardware?) というQuora記事の翻訳が話題になっていたので共有したい(Quoraの英語記事, Qiitaの翻訳)。

この記事では複数の仮説が挙げられているが、要約すると
1. 「日本人の職人気質や完璧主義が、ソフトウェア開発のパレートの法則やアジャイル文化と合っていない」
2. 「ソフトウェア開発職を他の技術職と同じように新卒一括採用や専門軽視で採用している」
3. 「英語が話せず、海外では古くなった技術や開発スタイルが今も跋扈している」
4. 「国際標準との互換性を軽視する」
となっている。

日本の中から見ていると分かる部分分からない部分もあるだろうが、スラド諸氏はこの分析、どう感じるだろうか?

情報元へのリンク

15336424 story
プログラミング

GitHub、関数名やコメントからコードを生成・提案する「GitHub Copilot」を発表 68

ストーリー by nagazou
IMEの予測変換みたいな 部門より
GitHubは6月29日、開発者のコード作成を支援するためのAIプログラミング機能「GitHub Copilot」を発表した。開発者の生産性を向上させる目的のもので、関数名とコメントから関数のコードを丸ごと自動補完するなどの提案も行えるという。Microsoftの「Visual Studio Code」および「GitHub Codespaces」向けの拡張機能として提供されるとしている。登録を行うとテクニカルプレビュー版の招待が受けられるようになるとしている(CNBCITmediaTechCrunch)。

GitHub CopilotはOpen AIと提携してこのツールを開発したという。このAIは何十億行ものコードを使って訓練を受けており、コードを書き進めていくと途中でGitHub Copilotからコードの提案が行われるという。開発者はそうした提案を受け入れたり拒否したりできるとしている。

一方でこのOpen AIの学習にはGitHub上にあるGPLコードも使われていると見られ、GitHub Copilotがプロプライエタリコードを利用している扱いとなり、GPLに違反する可能性もあるのではないかとする指摘も出ている模様(eevee氏のツイート)。

あるAnonymous Coward 曰く、

現在はテクニカルプレビューだが、将来的にはこの機能をベースにした商用製品の発売を予定しているという。ただし関数名やコメントは「平易な英語で」記述する必要があるため、日本人プログラマーが活用するのにはまだ難しいだろう。

15333215 story
プログラミング

プログラミング言語を一つ学んだら別の言語も簡単に習得できるという考えは正しいのか? 165

ストーリー by nagazou
日本語覚えても英語は話せない 部門より
ミシガン大学教授のMark Guzdial氏は、同業のコンピューターサイエンス(CS)の教育者二人から、最初のコースでプログラミング言語を気にする必要はない。学生が概念をしっかり学んでいれば、次に学ぶ言語では最初に学習した言語の知識を応用できるとする意見を聞いたという。しかし、Mark Guzdial氏本人は、過去の経験などから二つ目の言語習得はそう簡単ではないとして、先の二人とは異なる考えを持っている(Mark Guzdial氏のブログGIGAZINE)。

LISPやMICRO-PLANNERのように、基本的な概念が全く異なる第二言語の学習は、第一言語の学習と同等かそれ以上に難しい可能性が高い。学生がデータサイエンティストになりたいのであれば、C言語を学ぶよりもRやPythonを学ぶ方が合理的だ。こうしたことから、Mark Guzdial氏は、「なぜ最初に学ぶプログラミング言語は重要ではない」という考え方が定着しているのか考えるようになったそうだ。 同氏の考えとしては、1960年代後半にCSカリキュラムが定義されたとき、プログラミングの数学的基盤に重点が置かれていた。このため、現在教育者になってるような人は、現代の学生と比較すると数学的に強い基盤を持っている。このため、言語の違いは表記法の違いに過ぎないと考えているのではないかとしている。
15263008 story
プログラミング

Qiitaが「今後はプログラマのことをエンジニアと呼称する」と宣言 155

ストーリー by nagazou
呼称 部門より
あるAnonymous Coward 曰く、

たまに燃えることのある「エンジニア」と「プログラマ」の呼称を巡る問題だが、プログラマのための情報共有サイトであったQiitaがガイドラインを改訂し、今後は「プログラマ」のことは「エンジニア」と呼ぶと宣言してまたちょっと燃えているようだ(Qiitaの発表, はてなブックマークのコメント)。

一般的には、プログラミングをする人が全て「プログラマ」である一方、「エンジニア」は機械エンジニアや航空エンジニアなども含めた技術者全般を指す言葉で、特にプログラミングをする人を指す言葉では無いと思うが、Qiitaでは「世の中のエンジニアの定義とは少しずれた定義とはなってしまいますが」と断った上で、同サイトにおいて以後エンジニアを「プログラミングの知識と経験を活用している人」に変更して、今後はこの定義を用いていくとしている。

昨今では未経験者が経緯を知らずにエンジニアを使っている例は非常に多くなったが、だからと言って世の定義と間違っていることを承知で間違った定義に改める理由はないと思うのだが、スラド諸氏の見解は如何に?

情報元へのリンク

15295857 story
プログラミング

ITエンジニア400人に聞いた使いたいプロジェクト管理ツール、1位は「Excel」 189

ストーリー by nagazou
デジタル方眼紙最強説 部門より
あるAnonymous Coward 曰く、

パーソルキャリア株式会社が運営するIT・テクノロジー人材のためのコミュニティ「TECH Street」が、日本国内のITエンジニア403名を対象とした「理想の開発環境」のWebアンケートを行い、その結果を発表したのだが、いろいろとツッコみどころ満載の結果にネット上に困惑の声が広がっている(アンケート結果, はてなブックマーク)。

特に注目度が高い項目としては「使いたいプロジェクト管理ツール: 1位 Excel 32.3%」「使いたいIDE: 1位 IDEは使わない 32.8%」「使いたいエディタ: 1位 サクラエディタ 38.0%」辺りであろう。またその他も、全体的にMicrosoft TeamsやMicrosoft Projectなどのランキングが高いのも特徴的である。

この結果に対しては、「使いたいではなく使っているでは」「日頃見かける話と違う」「回答者の42.9%がSEで、60%超が40代以上だからでは母集団が偏っているのでは」「むしろ日本の平均を表しているのでは」などの様々なコメントが寄せられている。サクラエディタはともかく、プロジェクト管理ツールでExcelは無いと思うのだが、世の中こんなものなのだろうか?

情報元へのリンク

15511836 story
Java

Apache Log4j 2 で非常に深刻なリモートコード実行の脆弱性が見つかる 69

ストーリー by headless
深刻 部門より
Apache Log4j 2 でリモートコード実行の非常に深刻な脆弱性 (CVE-2021-44228) が見つかり、修正版の Log4j 2.15.0 が公開された (Apache Log4j Security VulnerabilitiesThe Register の記事LunaSec のブログ記事The Verge の記事)。

この脆弱性はLog4j 2 の JNDI 機能が攻撃者にコントロールされた LDAP やその他の JNDI 関連エンドポイントに対する保護を行わないというもので、Log4j 2.0-beta9 から 2.14.1 までのバージョンが影響を受ける。攻撃者は脆弱性のある Log4j 2 に特定の文字列をログとして記録させることで、LDAP サーバーから任意のコードを読み込んで実行させることが可能だ。この脆弱性を使用するエクスプロイトが既に公開されており、「Log4Shell」などと呼ばれている。

これについて あるAnonymous Coward 曰く、

Java のログ出力ライブラリ「Apache Log4j」にリモートコード実行 (RCE) の脆弱性が存在することが明らかになった。

この脆弱性を悪用するために特別な設定は不要で、「Apache Struts 2」、「Apache Solr」、「Apache Druid」、「Apache Flink」などが影響を受けるとのこと (窓の杜の記事)。

プログラムで Java を導入しているところは Log4j も入っているものと考えると影響は広範囲に及ぶものと見られ、GitHub では Apple、Steam、Minecraft などでの実証した画像が公開されている。

15252709 story
プログラミング

超一流プログラマーになるには3万時間のプログラミングが必要 133

ストーリー by nagazou
経験値表記にすれば気が紛れるかも 部門より
あるAnonymous Coward 曰く、

https://gigazine.net/news/20210404-5-programmers-30000-hours/

プロになるには1万時間の練習が必要という1万時間の法則というのがあるが、ドナルド・クヌース(The Art of Computer Programmingの著者)やスティーブン・ウルフラム(Mathematicaの作者)クラスになるには、3万時間超のプログラミングが必要なようだ。

情報元へのリンク

何事も一流のスキルを身につけるには1万時間の練習が必要とする「1万時間の法則」なるものがマルコム・グラッドウェルによって提案されている。この法則の自体の是非はさておき、プログラマーのBreck yunits氏は、実際に1万時間プログラミングしてみて、実際にその効果に自信を持てなかったそうだ。そこで自身が尊敬する著名なプログラマー25人にプログラミングに費やした時間を問い合わせたという。そのうち返答は5人あり、その結果をGitHub上で公開したという(GitHubGIGAZINE)。

なお返答のあった5人は以下の通り。

いずれも3万時間以上プログラミングに時間を費やしており、yunits氏は次は3万時間を目指すとしている。

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...