Perl 6、正式に「Raku」へ名称変更か | スラド デベロッパー
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
Perl 6、ついにリリース | スラド デベロッパー
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用のインストールパッケージ
GNU Emacs、プロジェクトのソースコード管理ツールをBazaarからGitへ移行させる | スラド デベロッパー
GNU Emacsが、プロジェクトで使用するソースコード管理ツールをBazzarからGitに移行させた（Phoronix）。 以前、「オープンソース」という言葉を広めた人物としても知られるEric S. Raymond氏がEmacs開発者向けメーリングリストに「Bazaarは死につつある」としてBazzarからの移行を提案していた（スラッシュドットの過去記事）ことも移行のきっかけになったようだ。 Emacsのソースコードを公開するGitリポジトリ自体は以前から存在したが、Emacsは非常に長い歴史のあるソフトウェアということで、その過去の履歴までを含めてGitに移行させるのは大変な作業だったようだ。 なお、リポジトリの情報やGitを使ったEmacsの開発手順についてはEmacs Wikiにまとめられている。
プログラムを書いたことがある最も尋常でない場所は？ | スラド デベロッパー
尋常でない場所や状況でSASプログラミングをしたことがあるかという4つの質問がSAS Blogsに掲載されているが、個人的には範囲をプログラミング全般に広げたら面白いのではないかと思う。4つの質問は次のようなものだ。 プログラムを書いた場所の中で、最も尋常でない場所 プログラムを書いた状況の中で、最も尋常でない状況 プログラムを書くのに使用した、最も尋常でないコンピューター環境 これまでにプログラムを書いた中で、最も尋常でないアプリケーション
「Pythonコードは欠陥が少ない」という調査結果 | スラド デベロッパー
オープンソースで公開されているさまざまなソフトウェアの品質を調査したところ、Pythonが最も高かったという調査結果が発表された（本家/.）。 この調査では、「不具合率（defect density）」という基準を使ってソフトウェアの品質を調べたという（関連するSourceForge.JP Magazineの記事）。一般的に「品質がよい」とされるソフトウェアの不具合率を「1.0」とし、それと比較して「不具合率」を算出したそうなのだが、その結果、オープンソースソフトウェアの不具合率は0.69と、一般的な「品質のよいソフトウェア」よりも欠陥が少ないということが分かったそうだ。 さらに、Pythonコードのみに限った場合は不具合率は0.005と大幅に低かったそうだ。これは、1000行のコード中に不具合が0.005個見つかる、という割合らしい。 また、Python本体のソースコード約40万行のうち
プログラマーとしての最大の恐怖は？ | スラド デベロッパー
ソフトウェア開発者は往々にして冷静で分析的であるが、彼らを震え上がらせるような状況が無い訳ではないだろう。ITworldのブロガーPhil Johnsonが開発者フォーラムで「プログラマーとしての最大の恐怖は？」との質問を投げかけ彼らの声を聞いたところ、回答は「特定の技術を使うよう強いられた」から「能無しと働くこと」など大まかに5つのカテゴリーに分類されたとのこと。これを読んでるあなたの最大の恐怖はなんだろうか？ この5つのカテゴリーとは、 「無能なマネージメントもしくは同僚」「ある特定の技術を使うこともしくは習うことを強いられる」「仕事が嫌いになること」「仕事を失うこと」「失敗すること」 だという。この中でも最大の恐怖として挙げられたのは、取り返しのつかないバグを作ってしまうといった「失敗すること」だそうだ。
自分の手柄を横取りされた、さあどうする？ | スラド デベロッパー
本家/.記事「Ask Slashdot: What To Do When Another Dev Steals Your Work and Adds Their Name?」にて、「自分の作成したソースコードのクレジットを書き換えられた」という話が取り上げられている。本家/.のタレコミ人曰く、 自分が開発したアプリケーションに関し、とある状況が持ち上がってきてしまった。 2年程前にある顧客のためにウェブアプリケーションをいくつか開発したのだが、この顧客との仕事はもう終わっており、現在は新しい開発者がメンテナンスを担当している。 新たな仕事を探すにあたりのポートフォリオにこのアプリケーションを実績として記載したところ、採用面接にてこの経歴が虚偽であると指摘されてしまった。いくつかのJavaScriptファイルを見せられたところ、なんとメンテナンス担当の開発者が私の名前を削除し、自分の名前を著
東証曰く、システム開発においてコーディング後にはドキュメントは不要 | スラド デベロッパー
2005年に発生した、「ジェイコム株大量誤発注事件」はみずほ証券に大きな損害を与えた。みずほ証券はこの損害の原因の1つに東証の売買システムのバグがあるとして、東京証券取引所（東証）に対し賠償を求める裁判を起こしていたのだが、この裁判が3月18日に結審した（日経ITpro）。これを受けて、日経コンピュータが「みずほ証券-東証裁判の争点を洗い出す」として争点をまとめている。 ここで興味深いのは、東証の開発手法やソースコードに対する姿勢だ。東証はソースコードの修正時にそれに対応するドキュメントの修正を行っていなかったそうなのだが、これについて「コーディングが終了した後はドキュメントは不要」と主張している。いっぽうのみずほ側はこれについて「ソフトウェア工学の知見を無視する暴論だ」として、重大な過失であると主張している。 また、ソースコードには著しい重複があったことが判明しているのだが、これについて
DeNA、JavaScriptコードに変換して実行する新言語「JSX」を公開 | スラド デベロッパー
DeNAが新しい言語「JSX」を公開した（SourceForge.JP Magazine）。 JSXは厳密な型付け機構を持つオブジェクト指向言語。Javaのようなクラスやインターフェイスを持ち、またJavaScriptのような無名関数やクロージャ機構も備えている。モジュール機構も用意されている。 ライセンスはMITライセンス。開発者の奥一穂氏による発表スライドによると、JavaScriptの生産性が低い、遅い、メモリを食う、といった問題点を解決するものだという。
プログラマ採用のための「オンラインコーディングチャレンジ」 | スラド デベロッパー
米国のベンチャー CodeEval が、技術系人材採用のためのプラットフォームを一般公開したそうだ (TechCrunch JAPAN の記事より) 。 CodeEval は「プログラミングスキル」をテストするためのプラットフォームを提供するサービスで、プログラマに対し実際にコーディングを行ってもらうことでそのスキルを事前に調査できるという。テストは CodeEval によって用意されるため、「技術に疎い採用担当者でもスキルの高い技術者を選抜できる」という。対応言語は 10 種類だそうで、無料版とより高機能な有料版が用意されているとのこと。どのようなテスト問題が提供されるのか気になるところだ。
プログラマーの情熱を奪わない開発プロセスとは？ | スラド デベロッパー
テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。コードを100%レビューする。単体テストでのコードカバー率を70%にする。循環的複雑度を20以下に抑える。開発を始める前に顧客の要望を調整しておくなど。大量の「ベストプラクティス」は、それぞれ素晴らしいアイディアのように見える。しかし、ベストプラクティスをこなすことに追われる開発者には、革新的・創造的な作業をするための時間がどれぐらい残されるだろうか。 O'Reilly Radarの記事では、良いコードを確保するために取り入れるプロセスが多すぎると、開発者の情熱を奪ってしまうと主張している。 「素晴らしいコードを書くことのできるプログラマーから、プロセスが情熱を奪う。不満を抱くプログラマーが質の悪いコードを書き、良いコードを確保するために管理部門がプロセスを追加する、という悪循環に陥り、さらに士気が低下する」というこ
IE9、SunSpiderベンチマークでズルしてる？ | スラド デベロッパー
ストーリー by hylom 2010年11月19日 15時35分 ベンチマークに向けた最適化、というのはよくある話 部門より IE9がSunSpiderベンチマークで「ズル」をして、実際よりもよいパフォーマンスを出しているのではないか？ ということが本家/.にて話題になっている。 SunSpiderはアップルによって開発されたベンチマークテストであり、ブラウザのJavaScriptエンジンのパフォーマンスを計るのによく使われている。このベンチマークでIE9がずば抜けてよいパフォーマンスを出しているそうなのだが、これが意図的な細工のではないかとの推測がdigitizorにて紹介されている。 これによると、MozillaのエンジニアRob Sayre氏がFirefox 4のテストを走らせていたところ、SunSpiderのmath-cordicテストにおいてChromeやOperagaのスコア
Rubyコアの開発は一度終わってみるべき | スラド デベロッパー
Rubyコミッタでもある卜部昌平氏が自身のtumblrにRubyがそろそろ一回終わってみるべき10の理由という書き込みを行っている。 そこでは、Rubyのコア部分の開発が一度終わってみるべきという主張が書かれており、その理由がずらずらと並べられている。 LinuxではLinusが優しい独裁者となっているように、Rubyではまつもとゆきひろ(Matz)氏が独裁者となっている開発コミュニティが形成されているが、Matz氏がいろいろと忙しくなる中で、彼が抱え込んだままになっているものが多すぎて開発が停滞し、強制力のある議決のようなものも発効できないということ。また、意思疎通がIRCに閉じていることで、IRC非参加者や日本語ができない外国人の参加への壁を作っていること。そして、人材の消費が激しいわりに、人材の流入がないことなどを理由として上げている。 これらの問題を解決する手段として、Matz氏が
Perl 6の「新しもの好き」向けディストリビューション「Rakudo Star」リリース | スラド デベロッパー
7月29日、Perl 6ディストリビューション「Rakudo Star」がリリースされた。ソースコード及びWindows向けバイナリがGitHubで公開されている。 「Rakudo Star」は「early adopters」、つまり「新し物好き」「人柱」向けのリリースで、まだバグを含み、速度的にも不十分、かつPerl 6の新しい言語仕様の一部は未実装という状況だそうだ。しかし、アプリケーションを開発する十分な能力を備えており、楽しいものになっているという。 Rakudo StarにはRakudo Perl 6コンパイラやParrot仮想マシン、さまざまなモジュールやドキュメントなどが含まれており、今後毎月定期的にバグフィックスや修正を加えたリリースを行っていくとのこと。 Rakudo Starの機能については、rakudo.orgのアナウンスを参照されたい。
割り込み頻度を3956Hzにする「心理視覚最適化パッチ」、LKMLに投稿される | スラド デベロッパー
LKMLにおいて、Linuxカーネルの割り込み頻度の心理視覚最適化パッチが提出されている (メーリングリストのメール）。具体的には人間が約0.5ms以下の変化が認識できないことを利用して、割り込み頻度を3956 Hz (何故？) にするだけであるが、グラフィックワークステーションやOpenGLアプリケーションに有益かもしれないとしている。60fpsの場合フレーム間隔は16.66msで、約0.5msとなると約2000fpsとなるわけであるが、ディスプレイや処理速度やアプリケーションの限界があるなかで違いが感じられるのだろうか。 iPhone 4では「10～12インチ離れた距離で人間が認識できる限界は300dpi」ということで解像度を360dpiに設定しているし（GIZMODOの記事）、画像形式や動画形式においても知覚的均等性を重視したLab色空間や、x264における複雑さを考慮した量子化量調
Webプログラミングにおいて、すべての言語はセキュアでない | スラド デベロッパー
しばしば、「○○というプログラミング言語は△△に比べて安全だ」「Webプログラミングの分野において最も安全な言語は何？」といった主張が繰り広げられることがある。これに対しSecurity Ninjaが「どの言語を選択しても関係ない、（なぜなら）それらは等しくセキュアでないからだ！」と反論している。 記事ではWhite Hat Securtyの統計レポート を元に、「どの言語も脆弱性がある入力の割合は大差なし」「かつて重要な脆弱性があったWebサイトの割合はどの言語でも70～80％台」「現在でも脆弱性があるWebサイトの割合はどの言語でも50～70％台」といったデータが示されている。このデータではPerlで実装されたWebサイトについて若干脆弱性が多いように見えるものの、結論としては「どの言語も等しくセキュアでない」とのことで、「セキュアなコードはセキュアな開発プロセスや開発者に対するセキュ
「Flash で開発する権利があるわけではない」？ | スラド デベロッパー
ストーリー by reo 2010年05月10日 12時00分 権利がある事とそれが尊重される事はセットではない 部門より 「Flash で (iPhone や iPad 用アプリケーションを) 開発する権利があるわけではない」との論が本家 /. 記事にて紹介されている。 ゲームデザイナーであり、大学で教鞭もとっている Ian Bogost 氏は以下のような主張を氏のブログ記事にて展開しているとのこと。 多くの開発者が iPhone 用 (もしくは他の端末用) のソフトウェアを Flash やその他任意の環境で開発する権利があると考えているようである。「その機会や利便が存在する」というのではなく、文字通り「権利がある」と考えているようであり、この問題に対し粗野な態度で構えている者も多いように思う。 このような態度は自分にはいささか奇妙に映る。Flash は便利であり普及もしており、広く浸透
プログラミングはプロポーショナルフォントの方が読みやすい ? | スラド デベロッパー
/.er はプログラミングにはどんなフォントを使っているだろうか? プログラマーである Maas-Maarten Zeeman 氏は自身のブログで「プロポーショナルフォントは等幅フォントよりも 14 % 速く読める」との研究を例にあげ、プロポーショナルフォントの使用を勧めている。 同じテキストを等幅フォントとプロポーショナルフォントで表示させた場合、プロポーショナルフォントの方が短い幅で済み、短時間で読めるとのこと。また、例えば同じ文字数の単語であったとしても、その文字種によって単語の表示幅が微妙に異なる方が単語認識を素早く行えるという。 ちなみに Zeeman 氏のお気に入りフォントは OS X では Lucida Grande、Windows では Lucida Sans だそうだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
括弧の始まりを「カッコ」、括弧の終わりを「コッカ」と呼ぶ？ | スラド デベロッパー
Appleはプログラマーを「Cool」なものにしたか？ | スラド デベロッパー