ブックマーク / developers.srad.jp (5)

  • 奴隷制を連想させるとして、Pythonで「master」「slave」といった単語が削除される | スラド デベロッパー

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

  • VB6ランタイムはWindows 10でもサポートされる | スラド デベロッパー

    MicrosoftWindows公式ブログにて、Visual Basic 6(VB6)のランタイムがWindows 10でもサポートされることを明らかにした。 VB6は今から約17年前の1998年にリリースされた開発ツールであり、.NETではない「旧来型VisualBasic」の最後のバージョンである。開発ツール自体のサポートはとっくに終了しているが、経験の少ないプログラマでも短時間で開発を行うことが可能なシンプルな構造であることから、未だに根強い人気がある。 約3年前に、MSDN MagazineのコラムニストDavid Platt氏が「ビールを賭けてもいい。MicrosoftWindowsが9や10になってもVisual Basic 6をサポートしなければならないだろう」と述べていたことがスラドで話題になったが、この予測は見事に当たったようだ。

    yujin_kyoto
    yujin_kyoto 2015/07/06
    さりげなく有用な情報が詰まってる。無用な情報も。
  • ソースコードを分析してその著者を特定するシステムが開発される | スラド デベロッパー

    ストーリー by hylom 2015年01月30日 14時32分 コード品質判定システムなんかも作れるかも? 部門より Drexel Universityとthe University of Maryland、the University of Goettingen、Princetoの研究者らが、ソースコードを分析し、その記述スタイルからその著者を検出する「code stylometry」なるシステムを開発したそうだ(Slashdot)。 実験では著者が明らかになっているソースコードを自然言語処理や機械学習といった技術を使って分析・学習するシステムを開発。250人の著者、1人の著者当たり平均630行のコードを学習させたところ、95%の成功率で「匿名のコード」の著者を見つけられたという。 また、学習に使用したソースコードの著者数を30人に減らし、また1人あたりのソースコード量を1900行に

  • コーディング能力を数値化するプログラマ選考支援ツール「HackerMeter」 | スラド デベロッパー

    「プログラマが足りないんじゃない、優秀なプログラマが足りないんだ」という雇用者の皆様、コーディング能力を数値化するサービスHackerMeterというサービスがありますよ。もちろん自分の能力を正当に評価してもらいたいプログラマの皆様も嬉しいですね(Techcrunchに日語の紹介記事があります)。 HackerMeterでは提示された「お題」を解決するためのコードを作成させることで、そのスキルを採点するサービス。コーディングやテスト、解答はすべてWebブラウザ上で実行する。対応言語はRubyPythonJava、C、C++。面白いのは、ブラウザ上でのコード入力がすべて記録されるという点。プログラマを探している雇用者は、その候補者のコードだけでなく、どのようにコードを作成しているのかというのを確認できるという。

  • 東証曰く、システム開発においてコーディング後にはドキュメントは不要 | スラド デベロッパー

    2005年に発生した、「ジェイコム株大量誤発注事件」はみずほ証券に大きな損害を与えた。みずほ証券はこの損害の原因の1つに東証の売買システムのバグがあるとして、東京証券取引所(東証)に対し賠償を求める裁判を起こしていたのだが、この裁判が3月18日に結審した(日経ITpro)。これを受けて、日経コンピュータが「みずほ証券-東証裁判の争点を洗い出す」として争点をまとめている。 ここで興味深いのは、東証の開発手法やソースコードに対する姿勢だ。東証はソースコードの修正時にそれに対応するドキュメントの修正を行っていなかったそうなのだが、これについて「コーディングが終了した後はドキュメントは不要」と主張している。いっぽうのみずほ側はこれについて「ソフトウェア工学の知見を無視する暴論だ」として、重大な過失であると主張している。 また、ソースコードには著しい重複があったことが判明しているのだが、これについて

  • 1