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

C言語を拡張して安全性を高めた「Checked C」をMicrosoftがオープンソース化した(InfoWorldの記事、 Softpediaの記事、 Microsoft Research — Checked C)。 Checked CはC言語にポインタの境界チェック機能を追加したことが名前の由来となっている。チェックに対応する新しい種類の配列型やポインタ型が追加されており、スコープを指定してチェックを強制することもできる。チェック機能を使用しない既存のCプログラムもそのまま使用できるため、後で徐々にチェックを有効にしていくことも可能だという。 現在、Checked CはLLVM/clangをフォークして実装されており、いずれはアップストリームへのマージも計画しているという。ソースコードはGitHubのChecked C clangリポジトリおよびChecked C LLVMリポジトリから

捜索や救助、マッピング、農業や工業の監視業務などに活用されているドローンだが、米海軍研究局（ONR）が開発した「LOCUST（低コスト無人航空機群）」は、ドローンの集団が情報共有を行い自律協調的行動を可能にするシステムを備えている（過去記事）。そして、最近になってこうしたチーム行動を単一のプログラムで処理するためのプログラミング言語「Buzz」が登場したという（論文、Slashdot）。 このプログラミング言語は簡単なプログラムで複雑なタスクが必要となる自己組織化挙動を可能にしているという。言語の詳細や実施例などはGitHubで公開されている。

ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事

私は自分をコードの書ける人間だと思っているが、プログラマーではない。アルゴリズムを考えることや、簡単なスクリプトを書くことは楽しいが、少し複雑なコードになるとお手上げだ。これは我慢強さが足りないだけかもしれないが、実際いつまでテキストベースでコードを書かなくてはいけないのだろう。言語に依存せず、暗号のような専門用語を使わずにアルゴリズムをコンピューターの理解できるものに変換する、より単純で堅牢な方法が必要ではないだろうか。今はまだアセンブリコードの1つ外側の抽象化レイヤーの中にいるように感じる。誰もがコードを書けるようになるグラフィカルなコード生成方法がないのはなぜだろうか。少なくともシンタックスエラーを修正するのにかかる時間をなくすことができればいいと思う。疑問は尽きないが、私の見落としているところがあれば教えてほしい。

Hacker Newsにて「The Worst Programming Environment in the World?」（世界最悪のプログラミング環境は？）という記事が話題だ。元ネタとして挙げられているのは、BANCStarというプログラミング環境。 BANCStarは財務・金融アプリケーション向けのプログラミング言語で、元々はNational Financial Computer Services, IncのBANCStarというアプリケーションの内部言語として作られたものらしい。この言語は数字とカンマ（「,」）、マイナス記号、キャリッジリターンでのみ構成されており、これだけですべてのプログラムを記述しなければならない。元々は別の開発ツールで作成したプログラムを変換ツールでこの言語に変換して利用する、といった使われ方を想定していたようだが、その開発ツールの制限により、直接このコードを

オーストラリアのソフトウェア会社Atlassianがエイプリルフールのためにパロディー動画を作った。ネタは2人のプログラマが1台のPCでソフトウェアの共同開発を行う「ペアプログラミング」。動画ではプログラマーがもう一人の膝の上に乗り、二人同時にキーボードを叩くというシュールな光景が映し出されている（Atlassianの動画、本家/.）。 もちろんこれはジョークなのだが、The Wall Street Journalではペアプログラミングの難しさについても言及されている。本来のペアプログラミングは、コードを書く役割の「ドライパー」とバグがないかチェックする「ナビゲート」の役割に分かれ、書かれたコードを作ったそばからチェックしていく、という点が特徴だ。これによってプログラミングのエラーを減らすことができ、一人で作業しているとありがちな、Webサーフィンで時間を潰してサボることもなくなると言うこ

英文で最も多く使われるアルファベットが「e」だというのはよく知られていますが、最も多く使われる単語は「the」だそうです。プログラミング言語ではどうなのか、GitHubで公開されているソースコードを解析した結果が発表されました(The Most Frequent Word in Source Code on GitHub: PDF)。 調査ではソースコードからコメント行を除外し、アルファベットと数字のみが連続する部分を単語として検出しています。調査対象となった10種類のプログラミング言語全体で、ソースコードに最も多く登場する単語はなんと「0」で、次に「if」が続くという結果になっています。 「if」のように良く使われそうな予約語が1位というのなら解りやすいのですが、「0」が圧倒的多数で1位の座を獲得したことに素直に驚きました。マジックナンバーは使用厳禁と言いながらも、考えてみれば初期化等に

5 年ぶりに開催された IOCCC (International Obfuscated C Code Contest、国際分かりにくい C のコードコンテスト) 参加者によるソースコードが公開されている。 受賞者はすでに発表されているが、どのコードも開いた瞬間に吹き出すレベルの難解さである。

コードを書くプログラマにとって、ドキュメント制作作業は「本来の仕事とは違う」と思いがちで、基本的には苦痛を伴うもののハズ。Made by Knight のブログ記事 "Documentation as a Bug-Finding Tool" ではバグ発見ツールとしてのドキュメンテーションについて述べられている (本家 /. 記事より) 。 ドキュメントは別の開発者にコードが引き継がれたときに、どのように動作するかという理解させるものだ。書いている自分以外「もう二度と見ないのでは」と思うコードでも、内部構造を手早く要約したドキュメントは、すべてを再チェックして構造を把握し直したり、書いた当時の忘れていた記憶を呼び戻す役割を持つ。しかし、ドキュメントを書くメリットはそれだけではない。書くためにコードを再チェックする過程で、小さなバグを発見できる可能性があるのだ。大きなプログラムになると、小さな

Google+ で Rob Pike 氏が語ったところによると、C 言語の開発者、K&R の R であるところの Dennis Ritchie 博士が亡くなられた。70 歳 (Rob Pike 氏による Google+ への投稿) 。 長らく闘病中だったとのことで、先週末に自宅で息を引き取ったそうだ。

米国のベンチャー CodeEval が、技術系人材採用のためのプラットフォームを一般公開したそうだ (TechCrunch JAPAN の記事より) 。 CodeEval は「プログラミングスキル」をテストするためのプラットフォームを提供するサービスで、プログラマに対し実際にコーディングを行ってもらうことでそのスキルを事前に調査できるという。テストは CodeEval によって用意されるため、「技術に疎い採用担当者でもスキルの高い技術者を選抜できる」という。対応言語は 10 種類だそうで、無料版とより高機能な有料版が用意されているとのこと。どのようなテスト問題が提供されるのか気になるところだ。

テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。コードを100%レビューする。単体テストでのコードカバー率を70%にする。循環的複雑度を20以下に抑える。開発を始める前に顧客の要望を調整しておくなど。大量の「ベストプラクティス」は、それぞれ素晴らしいアイディアのように見える。しかし、ベストプラクティスをこなすことに追われる開発者には、革新的・創造的な作業をするための時間がどれぐらい残されるだろうか。 O'Reilly Radarの記事では、良いコードを確保するために取り入れるプロセスが多すぎると、開発者の情熱を奪ってしまうと主張している。 「素晴らしいコードを書くことのできるプログラマーから、プロセスが情熱を奪う。不満を抱くプログラマーが質の悪いコードを書き、良いコードを確保するために管理部門がプロセスを追加する、という悪循環に陥り、さらに士気が低下する」というこ

IT関連資格の平成21年度春期試験受付が始まった。願書の受付期間は平成21年1月13日（火）10時から2月18日（水）20時まで。実施試験区分は下記のとおり。 パスポート試験（IP）基本情報技術者試験（FE）応用情報技術者試験（AP）プロジェクトマネージャ試験（PM）データベーススペシャリスト試験（DB）エンベデッドシステムスペシャリスト試験（ES）情報セキュリティスペシャリスト試験（SC）システム監査技術者試験（AU）初級システムアドミニストレータ試験（AD）新しくITパスポートが増えたり、試験内容に午前２ができたり、PM試験が秋から春になったりと変更点が多いので各自よく確認して試験に臨みましょう。 ＃個人的にはITパスポートをうけてみたいけど、今回はPMを受ける予定。

MMORPGのTabula Rasaが2009年2月末をもってサービスを中止するというニュースを聞いて、サーバ/クライアントコードはその後どうなるのか気になった。他プロジェクトで参考にされたりするのだろうか？ 破棄されるのだろうか？ それとも、どこかのハードディスクに保存されっぱなしになるのだろうか？Tabula Rasaだけでなく、その他の多くの頓挫してしまったプロジェクトのコードはどうなったのだろうか？ その企業内でコードを再使用することも多いだろうし、コードを公開して脆弱性が見つかったりすればその企業の他製品にも影響する恐れもあるし、中止となったプロジェクトのソースコードがフリーに配布される可能性は皆無に等しいと思う。とはいえ、もしそのようなリソースが提供されれば他プロジェクトの開発にも有益な気がするのだが、どうだろうか？

Microsoftより、Silverlight 2.0の正式バージョンが公開された（Internet Watchの記事）。 Silverlightの動作環境は以下の通りだ。 Windows 2000以降のIE6/7/8 Windows XP/Vista/Windows Server 2003上のFirefox 1.5/2/3 Mac OS X 10.4.8以降のFirefox 1.5/2/3およびSafari このほかのブラウザ、たとえばWindows版Safariなどでは動作しないとのこと。 Adobeも間を置かずにAdobe Player 10を公開するなど、ブラウザ上でのマルチメディア環境の競争は今後さらに激しさを増していきそうだ。 なお、Silverlightのインストーラは作業ファイルを適当な場所に展開するため、ローカルセキュリティポリシーでファイル実行が制限されている場所に展開

ストーリー by nabeshin 2008年04月30日 19時15分 髭といえば、RMSも仲間に入れてあげて 部門より 本家ストーリより。プログラミング言語の繁栄とその創始者の髭との間には深い関連性があるようだ。衰退していく言語の創始者には髭がないのに対し、繁栄する言語の開発者には髭があるとのこと。元ネタのTamir Khason氏のブログでは、様々な言語の開発者の写真をたっぷり載せ、この論を展開している。 例えばオープンソースプロジェクトの16%はCでプログラミングされているそうだが、Cの創始者達は皆立派な髭を蓄えている。Perlの父、Larry Wall氏も髭アリだ。最近勢いのないC++においては繁栄期から現在にいたるまでBjarne Stroustrup氏の髭が変遷している。

私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。同じような思いをしている方はいませんか? もしあなたもそうなら、何があなたの潜在能力の開花を阻んでいるのでしょうか? もっと大事なこととして、こうした状況を打破するために何かやろうとしていますか? 私は若いころからプログラミングを楽しんでいて(Apple IIe上のBASICで覚えました)、いろいろな言語やプラットフォームを使い、大小様々な企業で働いてきました。悲しいことに私のキャリアで一定していたのは、私が割り当てられるプロジェクトは、プロジェクトの開始からお客さんの資金が無くなるまで、あてどなく漂流してしまうということです。ここ/.に集う開発者で、自分の企業を説得して「カウボーイ風コーディング」を止めさせるか縮小させるかし、ベストプラクティスを導入させるの

iNSIDEの記事によりますと、任天堂は拡張性に優れたOSとして「esオペレーティングシステム」を研究中で、開発されたプロジェクトコードはオープンソースとしてSourceForge.JPにて公開されています。 インターフェイス定義言語esidlでオブジェクトインターフェイスを定義し、C++言語でソフトウェアを記述することでOSの機能を自由に拡張できるのが特徴です。x86で動作し、開発ツールや追加ライブラリなども併せて公開されています。