奴隷制を連想させるとして、Pythonで「master」「slave」といった単語が削除される | スラド デベロッパー
Pythonのバグトラッカーに、「Avoid master/slave terminology」という要望が寄せられている。これは「多様性のため」に奴隷制度を連想させる「master」「slave」という単語を削除するほうが好ましいという提案だ（Slashdot、Motherboard、Register）。 そもそも「master」という単語は非常に多くの場所で使われており、たとえばバージョン管理システムGitでは「masterブランチ」という概念がある。そのため、これを変更するのは容易なことではない。また、master/slaveという単語は電子回路やソフトウェアアーキテクチャにおいて奴隷制とはまったく関係ない文脈で使われている。そして、「slave」を置き換えられる単語で適切かつ広く普及している単語はいまのところ存在しない。こういった理由から反対の声も出ていたが、最終的には「salve
現在の職場でどんな兆候が現れたら転職を考える？ | スラド デベロッパー
プログラミングの仕事をしている現在の職場をやめ、別の職場を探すべき9つの兆候をInfoWorldの記事でAndrew C. Oliver氏がまとめている。 Oliver氏によれば、9つの兆候は以下のようなものだ。プログラミングの仕事に限らず、スラドの皆さんが転職を考えるべき兆候というのはあるだろうか。 仕事の対象がレガシーと呼ばれる これまで出席していた会議に呼ばれなくなる 上司から差別的な扱いを受ける 品質標準がない 上司の決めた内容ではうまくいかないとチーム全員が同意しているのに、とりあえず仕事を進める アジャイル開発を表面的にまねただけのカーゴカルト的アジャイルが行われている 口頭ではなく書面でネガティブなレビューやパフォーマンス向上計画(PIP)を渡される ランダムに新たな必須要件が追加される リリースするソフトウェアで繰り返し問題が発生しているのに、やり方を変えようとしないチーム
米政府機関のオープンソースプロジェクトをまとめるCode.govが公開 | スラド デベロッパー
米政府機関のオープンソースプロジェクトをまとめ、政府機関に必要なリソースを提供する「Code.gov」が3日に公開された(ホワイトハウスのブログ記事、 VentureBeatの記事)。 オバマ政権では政府機関が開発したソフトウェアのソースコードを「People's Code」としてオープンソース化を推進している。これまでは各政府機関が個別にオープンソースプロジェクトを公開していたが、Code.govにより一か所からアクセスできるようになる。Code.gov自体もオープンソースプロジェクトだ。 また、Code.govの公開に先立ち、別の政府機関が開発したソフトウェアへのアクセスを容易にして重複するソフトウェアの購入を避けたり、複数の政府機関が共同で作業を勧めたりすることを容易にするFederal Source Code Policyが8月に公開されている。 現在のところ、Code.govで公
Microsoft、C言語を拡張した「Checked C」をオープンソース化 | スラド デベロッパー
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リポジトリから
ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち | スラド デベロッパー
ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事
アジャイルがユーザーや顧客企業に嫌われる理由 | スラド デベロッパー
「アジャイル」なソフトウェア開発がここ数年注目されているが、アジャイルなソフトウェア開発において特徴的な反復 (イテレーション) や柔軟性といった手法は、顧客やユーザーにとってはまとまりも終わりも無い開発手法に見えるという。これを取り上げたITWorldのブログが本家/.にて話題になっている。 アジャイル開発を好む開発者は多い。イテレーションはユーザのニーズを的確に反映できるだけでなく、対応すべき要件があがってきたとしても問題が大きくなる前に対処することが可能だ。各要件に一つずつ取り組むため、きちんとフィードバックを受けて問題が無いことを確認してから次の要件に着手することもできる。 しかしユーザにとってみると、アジャイル開発は不透明で分かりづらく、故に不安を生んでしまうもののようだ。まるで開発プロセスが無く、開発方針も定まっていないように見えると、アジャイルプロジェクトに加わったとある人は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
