Gitのデフォルトブランチを「master」から「trunk」に変更する動き | スラド デベロッパー
アメリカにおける黒人差別問題が再び大きく話題となる昨今だが、プログラミング界隈でもGitのデフォルトブランチ名である「master」が奴隷制に基づくものであるとして「trunk」に変えようという動きが上がっているらしい（outsider reflex、blacklist/whitelist master/slave に関する情報集め）。 特に大きな話題となっているのは、GitHub公式のCLIツールが、デフォルトブランチ名を「master」から「trunk」に変える変更を行った話である。この件についてのissueは反対意見も出ていたものの、管理者の一存で5月27日にマージされており、今後利用者に大きな影響を与えることになるとみられる。 なおGitでは「slave」は使われておらず、Gitの「master」は奴隷と関係ない「master」ではないかという意見もあるが、Gitの「master」
第三者によりPythonの商標が取られる | スラド デベロッパー
2013年、英企業がPythonの商標権を主張して騒動となったが（過去記事）、日本ではアークという企業が電子的コンテンツや教材・刊行物、コンサルティング、デザインなどの分野で「Python」の商標を2017年に出願し認められていたとのこと（Ruby開発者・まつもとゆきひろ氏のTweet、Pythonに関する執筆やコミュニティ活動などを行っている石本敦夫氏のTweet）。 アークは各種認定試験やセミナー、コンサルティングなどを行っている企業で、「【Python】Foundation／Expert／Master公認研修」という研修を提供している。PythonはPython Software Foundationという組織によって開発が行われているが、このPython Software Foundationとこの「Foundation／Expert／Master公認研修」との関係は不明。 また、
IPA曰く「ソフトウェア開発の生産性は年々低下傾向にある」 | スラド デベロッパー
ストーリー by hylom 2018年03月15日 16時35分 生産性を高めるために冗長な記述が求められる言語とフレームワークを導入すべきか 部門より 独立行政法人情報処理推進機構ソフトウェア高信頼化センター （IPA/SEC） は3月6日、近年のソフトウェア開発の傾向を分析した「ソフトウェア開発データが語るメッセージ2017」という資料を公開し、ソフトウェア開発の生産性は年々低下傾向にあるとの警鐘を発した（プレスリリース）。 この資料は2018年のソフトウェア開発データ白書用に収集したデータを元に作成されたもの。IPA/SECでは、新規開発プロジェクト全体におけるソースコード行数の生産性が年々低下傾向にあることに着目し、ここからソフトウェア開発の生産性が低下していると主張している。 データのさらなる分析の結果、この要因として「品質要求レベルが上昇している」「要員のスキルに低下傾向がみ
OracleがJava EEの開発から手を引く可能性 | スラド デベロッパー
OracleがJava EEの開発から手を引くのでは無いか、という噂が出ている。Ars Technicaが報じたもの（マイナビニュース）。 OracleがJava EEの開発に取り組む従業員に対しJava EE以外の仕事に取り組むよう指示が出たという話が出ているほかや、今後のJava EEの計画が明らかにされておらず、仕様の策定も進んでいないといった状況であり、近年ではJavaの仕様策定を行っているJCP（Java Community Process）に対するOracleの活動が減っているとの指摘（CodeZine）もある。また、OracleはKenai.comやJava.netのプロジェクトホスティング機能を1年後を目処に閉鎖することをすでに発表している（InfoQ）。 まだ最終決定は行われていないが、こういった状況からOracleがJava EEから撤退するのではないかとされている。
ウォーターフォールに何もメリットはない？ | スラド デベロッパー
ストーリー by hylom 2016年06月24日 18時25分 ウォーターフォールじゃないと下請けに丸投げできないのでは 部門より アジャイル開発が広がる昨今でも、大規模開発ではウォーターフォールといった考えが主流と思われるが、そうした考えを一蹴する、MicrosoftのDevOpsエバンジェリストの牛尾氏による「私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い」というブログが微妙に注目を集めている。 事の発端となったのは、先日来日した米Microsoftのプロジェクトマネージャで「No.1 DevOps Person」と呼ばれるサム・グッケンハイマー氏と日本企業とのやり取り。氏は企業からの「アジャイルと、ウォータフォールのメリット・デメリットを教えてください」との質問に対して「ウォータフォールは一切メリットがないので止めておきなさい」ときっぱり言い放ったとのこと。これ
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リポジトリから
アジャイルがユーザーや顧客企業に嫌われる理由 | スラド デベロッパー
「アジャイル」なソフトウェア開発がここ数年注目されているが、アジャイルなソフトウェア開発において特徴的な反復 (イテレーション) や柔軟性といった手法は、顧客やユーザーにとってはまとまりも終わりも無い開発手法に見えるという。これを取り上げたITWorldのブログが本家/.にて話題になっている。 アジャイル開発を好む開発者は多い。イテレーションはユーザのニーズを的確に反映できるだけでなく、対応すべき要件があがってきたとしても問題が大きくなる前に対処することが可能だ。各要件に一つずつ取り組むため、きちんとフィードバックを受けて問題が無いことを確認してから次の要件に着手することもできる。 しかしユーザにとってみると、アジャイル開発は不透明で分かりづらく、故に不安を生んでしまうもののようだ。まるで開発プロセスが無く、開発方針も定まっていないように見えると、アジャイルプロジェクトに加わったとある人は
プログラマーの情熱を奪わない開発プロセスとは？ | スラド デベロッパー
テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。コードを100%レビューする。単体テストでのコードカバー率を70%にする。循環的複雑度を20以下に抑える。開発を始める前に顧客の要望を調整しておくなど。大量の「ベストプラクティス」は、それぞれ素晴らしいアイディアのように見える。しかし、ベストプラクティスをこなすことに追われる開発者には、革新的・創造的な作業をするための時間がどれぐらい残されるだろうか。 O'Reilly Radarの記事では、良いコードを確保するために取り入れるプロセスが多すぎると、開発者の情熱を奪ってしまうと主張している。 「素晴らしいコードを書くことのできるプログラマーから、プロセスが情熱を奪う。不満を抱くプログラマーが質の悪いコードを書き、良いコードを確保するために管理部門がプロセスを追加する、という悪循環に陥り、さらに士気が低下する」というこ
もっと早く知りたかったプログラミングのコツは ? | スラド デベロッパー
ストーリー by reo 2010年09月09日 11時00分 他人のコードを読み、他人とコードについて語ること 部門より 本家 /. 記事にて Ted Dziuba 氏のブログエントリ「もっと早く知りたかったプログラミングのコツ」が取り上げられている。 Dziuba 氏はここ数年スタートアップ企業に関わっているそうで、痛い目にもいろいろ遭ってきたとのこと。その経験から荒削りな知識で何とかするよりも、理にかなったやり方を身につけるべきだと痛感したという。振り返ってみれば「早く知っていればよかった」ことや「意地を張らずに学べばよかった」と感じていることがいろいろあるそうだ。 例えば Linux がカバーできることであれば、自分で開発するべきではなく、「必要以上の複雑化は防ぐ」ということ。また「パラレル処理は『自分がやりたい時』にではなく、『必要に迫られた時』にのみ行うべき」であり、「最新の技
「ウォーターフォール開発」、本当に日本でうまく行っているのか？ | スラド デベロッパー
「Continuous Delivery」というソフトウェア開発に関する書籍の著者、Jez Humble氏によりますと、多くの日本IT企業は大規模ソフトウェア開発プロジェクトでウォーターフォール（Waterfall）な開発手法を取っているのですが、この開発手法は世界中で多くの失敗を引き起こしているにも関わらず、日本ではなぜかうまく行っているそうです（Humble氏のブログ記事）。 /.J諸兄方の職場では、ウォーターフォール開発手法で本当にうまく行っていますか？ また、今使っている開発手法は何ですか？ これは、7月21日に行われたAgile Conference Tokyo 2010でのトークセッションで話題にされたそうで、参加者のレポートやTwitter実況などによると、Humble氏は日本の開発工程に「バグフィックス工程」がないことに驚いたらしい。頻繁なテストやコーディング段階での修正が
引き継いだプログラム、「自分のもの」にするには ? | スラド デベロッパー
この仕事に就いてから、比較的大きなプログラム (3 ～ 4 万行程度) を何度か引き継いだことがある。元々の開発者らは、自分の書いたコードでもあるし (その仕様や動きを) よく理解していたが、自分はそこまでとは言えない。実際、プログラムに修正を入れる際は修正そのものよりも修正を入れるべき正しい位置を探すのに多くの時間がかかってしまう。 このように引き継いだプログラム、どうやったら理解できるようになるのだろうか ? 元の開発者らほどこのプログラムを「理解」できないのは自分の力量の問題ではなく、仕方がないことなのだろうか ? 本家 /. には「一から作り直したくなるだろうが、それは絶対に避けるべきだ。汚く見えるコードにも、全て理由があったりするものだ。開発時の相談や議論、意思決定までの過程にいなかったからコードが理解できないのである。一から作り直しても、そういった問題への理解は深まったりはしな
スラッシュドット ジャパン | プログラミングのカルト宗派
ざっと訳してみました 間違いあったら訂正よろしく ＃タレコミ時には訳もつけとけよ ■経験カルト 経験カルトのメンバーは、昔にやったことしかできないと信じています。 彼らを識別するには、彼らの手に余る問題を提示することです。 未使用APIへの恐怖にも似た反応や、サンプルコードの提示要求という特徴的な反応から識別できます。 対処：新しいことも実現できることを提示できれば、カルトからの解脱へ導けるかもしれません。 訳者からの追加セリフ： 「やったことないからできません」 「使えるサンプルコードを提示してください」 ■最適化カルト 最適化カルトのメンバーは、他のどんな価値観よりも速さに価値を見出します。 掲示板で「最速の方法は？」とよく質問しています。 速さの価値観にマッチしない意見を提示されると、狂ったような反応を示します。 同様に、どの操作が速くて、どんな操作が速くないかということに関して誤っ
Windowsで綺麗なフォントレンダリングを実現する「gdi++.dll」 | スラド デベロッパー
Meth610曰く、"すでに窓の杜などでも記事になっているが、gdi32.dllのTextOutやExtTextOutなどの関数をフックして、対象となるアプリケーションで高品位なフォントレンダリングを行う「gdi++.dll」が公開された。現在、作者のページからソースコードと共にダウンロードできる。"(続く…) "このdllは、2ch「WindowsのフォントスレッドVer.16」において、Windowsにおけるフォントレンダリングの汚さに業を煮やしたユーザーがオープンソース形態で開発を始めたもの。 当初は対象アプリケーションのバイナリを直接書き換えて読み込むdllを変更する方法を取っていたが、2006/09/20のバージョンでは同梱のgdi++.exeによりAPIを直接フックする方式に変更され、手軽に効果を試すことができるようになった。使用するフォントにもよるが、Webブラウザやエディタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Emacs上で動作するフルブラウザ | スラド デベロッパー
ペアプログラミング、実践してますか? | スラド デベロッパー