アメリカにおける黒人差別問題が再び大きく話題となる昨今だが、プログラミング界隈でもGitのデフォルトブランチ名である「master」が奴隷制に基づくものであるとして「trunk」に変えようという動きが上がっているらしい（outsider reflex、blacklist/whitelist master/slave に関する情報集め）。 特に大きな話題となっているのは、GitHub公式のCLIツールが、デフォルトブランチ名を「master」から「trunk」に変える変更を行った話である。この件についてのissueは反対意見も出ていたものの、管理者の一存で5月27日にマージされており、今後利用者に大きな影響を与えることになるとみられる。 なおGitでは「slave」は使われておらず、Gitの「master」は奴隷と関係ない「master」ではないかという意見もあるが、Gitの「master」

Perl 6の名称を正式に「Raku」へ変更するというGitHubでの提案に対し、Perl生みの親のLarry Wall(TimToady)氏が支持を表明している(Larry Wall氏のコメント、 blogs.perl.orgの記事、 The Registerの記事)。 次世代Perlとして開発されていたPerl 6だが、正式リリース後もPerl 5の開発が進められており、「Perl」といった場合にPerl 5を指す状態が続いている。そのため、Perl 6の名前に「Perl」が入っているのはわかりにくいとして、8月からGitHubで名称変更が議論されていた。このスレッドでは「Raku (楽)」という日本語について、勘違いも含めてちょっと面白い議論になっている。 もともと「Raku」という名前は昨年、Perl 6のエイリアスとして使えるもう一つの名前を付けてほしいというZoffix Zne

Pythonのバグトラッカーに、「Avoid master/slave terminology」という要望が寄せられている。これは「多様性のため」に奴隷制度を連想させる「master」「slave」という単語を削除するほうが好ましいという提案だ（Slashdot、Motherboard、Register）。 そもそも「master」という単語は非常に多くの場所で使われており、たとえばバージョン管理システムGitでは「masterブランチ」という概念がある。そのため、これを変更するのは容易なことではない。また、master/slaveという単語は電子回路やソフトウェアアーキテクチャにおいて奴隷制とはまったく関係ない文脈で使われている。そして、「slave」を置き換えられる単語で適切かつ広く普及している単語はいまのところ存在しない。こういった理由から反対の声も出ていたが、最終的には「salve

ストーリー by hylom 2018年03月15日 16時35分 生産性を高めるために冗長な記述が求められる言語とフレームワークを導入すべきか 部門より 独立行政法人情報処理推進機構ソフトウェア高信頼化センター （IPA/SEC） は3月6日、近年のソフトウェア開発の傾向を分析した「ソフトウェア開発データが語るメッセージ2017」という資料を公開し、ソフトウェア開発の生産性は年々低下傾向にあるとの警鐘を発した（プレスリリース）。 この資料は2018年のソフトウェア開発データ白書用に収集したデータを元に作成されたもの。IPA/SECでは、新規開発プロジェクト全体におけるソースコード行数の生産性が年々低下傾向にあることに着目し、ここからソフトウェア開発の生産性が低下していると主張している。 データのさらなる分析の結果、この要因として「品質要求レベルが上昇している」「要員のスキルに低下傾向がみ

Perl 6 Advent Calendarは24日、Perl 6のリリースをアナウンスした(Perl 6 Advent Calendar - Day 24、 Phoronixの記事、 6gutsの記事)。 2000年に言語の完全な刷新を目指して開発が始められたPerl 6だが、開発は遅々として進まず、15年の時を経てようやくリリースにこぎつけたことになる。Perl 6 Advent Calendarでは、まだ15歳の子供なので未完成な部分もあるが、今後数年の間により速く効率的になるとしている。Perl 6は「Advent(アルファ版)」「Birthday(ベータ版)」のように祭りや祝い事の名前が付けられており、リリース版は「Perl 6 Christmas」とのこと。 このPerl 6について、あるAnonymous Coward 曰く、 現時点でWindows用のインストールパッケージ

Microsoftは4月にBuild 2015でWindowsストアアプリを増やすための方策として、4つの「Windows Bridge」プロジェクトを発表した。このうち、AndroidアプリからWindowsユニバーサルアプリへの移植を可能にする「Windows Bridge for Android(Project Astoria)」の開発は計画通り進んでいないそうだ(Re/codeの記事、 The Registerの記事、 Windows Centralの記事、 BetaNewsの記事)。 8月にオープンソースプロジェクトとしてGitHubでプレビュー版が公開された「Windows Bridge for iOS(Project Islandwood)」ではそれなりに開発者によるコーディング作業が必要になる。一方、Project AstoriaはAndroidアプリのAPKファイルをWi

損害保険ジャパン日本興亜が、コスト削減や効率性向上のためCOBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替えるそうだ（日経ITpro）。 数年をかけて順次移行する計画で、現在のシステムでは年間で500億円以上もの保守費用がかかっているらしい。このプロジェクトは2015年4月からスタートしており、今年10月にはこのプロジェクトのために日立と合弁会社を設立するなどしている（発表PDF）。

新たな暗号通貨/分散処理システム「Ethereum」が先月末より稼働を開始した。当初は2014年末から2015年にかけての稼動開始が予定されていたもの。 Bitcoinを始めとする仮想通貨では、P2P上に形成したBlockchainで口座間の金額のやりとりの記録を行っている。そして、単なる数字の増減にとどまらず、さまざまなデータを管理させることでより高度な機能を実現しようというアイデアが生まれており、それらは「Bitcoin 2.0」「暗号通貨2.0」などと呼ばれている。 Ethereumはその中でも、独自のBlockchainによりチューリングマシンを実装しており、汎用言語でのプログラミングができることに特徴がある。つまり仮想通貨が銀行などの第三者機関を必要とせずに送金を可能としたように、Ethereumの登場によって第三者の特定のサーバに依拠せず、P2P全体を実行環境としてプログラムを

先日著名ゲームエンジン「Unreal Engine」のソースコードが公開された。ライセンスはオープンソースライセンスではないが、第三者がソースコードを閲覧できるようになったということでこのコードをC/C++向けのコード解析ツールを開発するPVS-Studioが解析したところ、多くの問題が見つかったそうだ（公表されている解析結果）。 これを受けて、Unreal Engineの開発物であるEpic GamesはPVS-Studioとパ－トナーシップを結び、問題を解決する方針を示したという（Epic Gamesの発表）。

ソースコード中の記述を整理したり、変数名や関数名を分かりやすく書き換えることはリファクタリングと呼ばれているが、実験の結果、リファクタリングを行ったとしてもコードの質が格段に良くなるものでもないことが分かったそうだ（ITWorld、Slashdot）。 調査を行ったのはスリランカの研究チーム。リファクタリングによりソフトウェアの品質が外部的・内部的にどれほど向上するのかを調べたそうだ。実験には、オンラインドキュメント評価のスケジューリングおよび管理を行う小規模のアプリケーション（4,500行ほどのC#コード）が用いられ、10個の一般的なリファクタリング技術が適用された。 実験の結果、実際の統計では大きな差はみられなかったもの、参加者らの採点によればリファクタリングされたコードの方が解析性が劣り、コードのバグ修正と実行にはより時間がかかるようになったという。また、リファクタリングしたからとい

Edsger Dijkstra氏がgoto文の危険性を主張したのは1968年。それから50年近く経過した現在もgoto文は使われ続けているが、Dijkstra氏が懸念したようなgoto文の無制限な使用が行われているのかどうかという点や、それがバグの原因となるような有害なものなのかどうかといった点については、よくわかっていなかったという。こういった点に関する実証研究が本家/.で紹介されている。 本家/.「Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"」より 200万近いC言語のファイルと1万1千件を超えるプロジェクトからランダムに抽出した統計的に有効なサンプルを質的および量的に分析したところ、開発者はほとんどの場合gotoの使用を適切に制限しており、Dijkstra氏が懸念したような無制限な使用は行わ

「プログラマ35歳限界説」という俗説があるが、実際のところ30代も半ばになると、マネジメント業務が増えて実際にコードに触れなくなるプログラマも少なくない。しかし、任天堂の岩田社長は、40歳、任天堂の経営企画室長時代まで実際にコードを触る業務に関わっていたという（4Gamer）。 岩田氏はマネージメント業務に関わるようになってもしばらくは夜や休日にコードを書き、社内で見せていたという。また、岩田氏が最後に関わったのは、ゲームキューブ版の「スマッシュブラザーズ」だそうで、開発が停滞し「このままだと発売日に間に合わない」という状況になったため、開発元である山梨のHAL研究所に赴いてコードレビューやバグ修正、バグの担当者割り当てと行った作業をやっていたそうだ。 岩田氏が社長になったのは2002年、42歳のときなので、その2年前まで実際にコードを触ることができていたというのは興味深い。さすがに現在は

GNU Emacsが、プロジェクトで使用するソースコード管理ツールをBazzarからGitに移行させた（Phoronix）。 以前、「オープンソース」という言葉を広めた人物としても知られるEric S. Raymond氏がEmacs開発者向けメーリングリストに「Bazaarは死につつある」としてBazzarからの移行を提案していた（スラッシュドットの過去記事）ことも移行のきっかけになったようだ。 Emacsのソースコードを公開するGitリポジトリ自体は以前から存在したが、Emacsは非常に長い歴史のあるソフトウェアということで、その過去の履歴までを含めてGitに移行させるのは大変な作業だったようだ。 なお、リポジトリの情報やGitを使ったEmacsの開発手順についてはEmacs Wikiにまとめられている。

MicrosoftがC#で書かれた.NET Framework向けのプログラムをネイティブコードにコンパイルする「.NET Native」を発表した。現在Preview Release版が公開されている(.NET Framework Blogの記事、 Microsoft .NET Native、 Microsoft .NET Native FAQ、 Compiling Apps with .NET Native、 本家/.)。 C#などの.NET系言語では、コードをコンパイルすると中間コードが生成され、実行時にネイティブコードに変換されるという仕組みを取っていたが、.NET Nativeを使えばC/C++による開発と同様にネイティブコードを生成でき、アプリケーションの起動速度の高速化やメモリ消費の削減といったメリットを享受できるという。対象アーキテクチャは現在のところx64およびARMで、

HTML5やUnityなど、Flashの代替となりうるプラットフォームが登場・普及しつつあるが、とあるFlashゲーム開発者によると、次に注目したいのは「OpenFL」だという（GAMASUTRA、slashdot）。 OpenFLはオープンソースで開発されている、FlashのAPIとほぼ互換性のある開発環境。マルチプラットフォーム対応のコンパイラ「Haxe」の技術を使い、デスクトップからモバイルまでさまざまな環境で動作するアプリケーションを単一のソースから生成できる。 15年間に渡ってFlashを使ってゲーム開発を行っているLars Doucet氏は、「はっきり言えばFlashは死にかけている」と主張している。その殺人犯はサポートを見捨てたAdobeだという。 Flashからの移行先となりうるプラットフォームにはいくつかがあるが、Unityは人気があるもののライセンス料の問題があり、また

このたびEmacs上でWebKitを動作させる方法が開発された（Emacs WikiのWeb Kitページ）。スクリーンショットも公開されている。 WebKitのフル機能が利用可能で、JavaScriptも動作する。ただしEmacsとWebKitは別プロセスで動作し、プロセス間通信でやり取りを行うという形になっている。利用にはPyQt5やPythonXlib、PythonEPCなどが必要。Windows上で動作するかは不明。

以前、「NTTデータ、既存システムのソースコードから設計書を自動生成するサービスを開始」という話題があったが、この技術を強化し、設計書だけでなく要件定義書までも生成できるよう開発を進めるという（日刊工業新聞）。 現在提供されている「設計書リカバリーサービス」は、ソースコードを解析してドキュメントや設計書を出力するというものだったが、これらに顧客の業務内容といった情報を加えることで要件定義書までも生成できるようにするという。まだ開発開始というレベルのようだが、今後は「解析によって生成した設計情報のチェック、新しい設計情報を元にしたアプリケーション（応用ソフト）の生成までの一連の流れを自動化する技術の高度化」を勧め、2015年度には開発工期を半減させることを目指すという。

MozillaのGregory Szorc氏が、なぜ多くのプロジェクトでPython2.7以前のリリースをサポートし続けるのかと問うている(Gregory Szorc's Digital Homeのブログ記事、 本家/.)。 以下、ブログ記事より抜粋。 Pythonプロジェクトのメインテナー達は、Python2.6を含むそれ以下のサポートをやめることを真剣に考えるべきだと思う。簡単に入手することのできるPython2.7を持たないシステムを使っている人がそんなに沢山いるだろうか。我々Python開発者は、なぜ手間をかけてまで時代遅れとなっているPythonリリースのサポートを続けているのだろう。一例ではあるが、私はFirefoxのビルドシステムをPython2.5+から2.7.3+にうまく移行することができたし、比較的安易に行うことができた。 ブログに記事が投稿されてから間もなく、他の開発

国際難解Cコードコンテスト（International Obfuscated C Code Contest、IOCCC）第22回で入賞したソースコードが同サイトで公開された。 IOCCCは、「故意に読みづらいC言語のコードを書き、その汚さなどを競うというハッカーの奇祭」（Wikipediaより）。 複数の部門があり、それぞれ入賞コードが挙げられているが、日本人では遠藤侑介（Yusuke Endoh）氏が「Most tweetable 1-liner」wおよび「Most lazy SKIer」、「Most recyclable」、「Most solid」の4部門で入賞している。それぞれのコードは遠藤氏のブログで解説されている（「Most lazy SKIer」と「Most recyclable」のコードの解説、「Most tweetable 1-liner」と「Most solid」のコード