JavaアップデートでインストールされるJava、無償利用が一部用途にのみ限定されたバージョンに切り替わる | スラド デベロッパー
窓の杜の『「Oracle Java」のライセンスが変更 ～無償利用は個人での開発・テスト・デモ目的のみに』という記事、ライセンス変更なんてとっくの昔に発表されているだろと思ったら、今回が無償化終了後の初のアップデートで、一般のWindowsユーザー向けのJavaアップデートでも新しいライセンス（OTNライセンス）のJavaが落ちてくるようになった、ということだった。 アップデートの文面にあるように、職場のPCで何も考えずに更新を適用するとライセンス違反になり兼ねない。一方で、タイミングが悪いことに令和対応にはアップデートが必須なようだ。 京都教育大学の「Oracle Java SEの有償化に伴うOpenJDKへの切り替えの案内」という案内が良くまとまっているが、対策としてはAdoptOpenJDKなどのOSSプロジェクトがWindows向けのJRE/JDKビルドを提供しているので、そちらに
スラッシュドット ジャパン | Linus曰く「Subversionは史上最も無意味なプロジェクト」
Mona OS開発者ひげぽん氏のブログ記事で今さらながら知ったのですが、かのリーナス・トーヴァルズが、「Subversionは史上最も無意味なプロジェクト」とこきおろしていたそうです。 元ネタはリーナス氏が半年ほど前にGoogleで行ったgitに関する講演(YouTubeビデオ)で、satologのブログ記事によれば ぼくの CVS への憎悪が意味するのは、ぼくが Subversion のことを史上最大の無意味なプロジェクトだと見ているということだ。Subversion がしばらくの間スローガンにしていたのに、「ちゃんとした CVS」みたいなのがあったよね。そんなスローガンでスタートしたら、もうどこにも行くところがない。CVS をちゃんとすることなんて不可能だからだ。 と述べていたとのこと。「CVS が好きな人は精神病院に行ったほうがいい」「tarボールとパッチのほうがはるかに優れたソース
サポート終了まで1年半のWindows 7、相変わらず高いシェアを維持 | スラド デベロッパー
StatCounterの7月分Windowsバージョン別シェアデータによると、前月にリリース以来初めて減少したWindows 10は0.5ポイント増の47.25%となり、過去最高シェアを更新した。 一方、2位のWindows 7は0.57%減の39.06%で、2011年7月以降では最低シェアとなっている。しかし、Windows 7の延長サポートは2020年1月14日で終了するので、既にサポート終了まで1年半を切った状態だ。Windows XPでさえサポート終了1年半前(2012年10月)のシェアは30.81%であり、Windows 7は高いシェアを保っているといえる。なお、当時のWindows全体のシェアは91.04%だったため、Windowsバージョン別シェアをデスクトップOS全体に換算するとWindows XPが28.05%、Windows 7が54.91%となる。一方、7月のWind
アジャイルがユーザーや顧客企業に嫌われる理由 | スラド デベロッパー
「アジャイル」なソフトウェア開発がここ数年注目されているが、アジャイルなソフトウェア開発において特徴的な反復 (イテレーション) や柔軟性といった手法は、顧客やユーザーにとってはまとまりも終わりも無い開発手法に見えるという。これを取り上げたITWorldのブログが本家/.にて話題になっている。 アジャイル開発を好む開発者は多い。イテレーションはユーザのニーズを的確に反映できるだけでなく、対応すべき要件があがってきたとしても問題が大きくなる前に対処することが可能だ。各要件に一つずつ取り組むため、きちんとフィードバックを受けて問題が無いことを確認してから次の要件に着手することもできる。 しかしユーザにとってみると、アジャイル開発は不透明で分かりづらく、故に不安を生んでしまうもののようだ。まるで開発プロセスが無く、開発方針も定まっていないように見えると、アジャイルプロジェクトに加わったとある人は
ついつい使ってしまうプログラミングの悪いテクニックは？ | スラド デベロッパー
プログラミングの際に、さまざまな理由でコーディングのルールを破ってしまうことがある。これらは誰もが「悪い」プログラミングテクニックであると認めるようなものだが、結果としてコードがクリーンになり、高速かつシンプルになることもある。InfoWorldの記事では、愛される悪いプログラミングテクニックを9つ選んでいる。 InfoWorldが選んだ悪いプログラミングテクニックは以下の通り。 gotoを使う 関数名だけで内容がわかるようにしてドキュメンテーションを避ける 1行に大量のコードを詰め込む 型宣言をしない 値の型を繰り返し変換する「ヨーヨーコード」 独自のデータ構造を書く ループの半ばでループを抜ける 短い変数名を使う 演算子や関数を再定義する プログラミング言語や環境によっては使用できないものもあるが、皆さんがよく使うものはあるだろうか。また、リストに追加するとしたらどのようなものがあるだ
「プログラミング時専用BGM」を収録したアルバムがリリースされる | スラド デベロッパー
MIDI楽器を使用してプログラムコードを入力する試みが以前話題となったが、今度はプロのミュージシャンでプログラマーのCarl Franklin氏が、コードを書く時に特化したBGMのアルバムをリリースした。Franklin氏は「最も難しかったのは、本当の音楽を作ることに私の本能を戻すことだった。」と、ITworldのPhil Johnson氏に語る。「この音楽はバックグラウンドに溶け込む必要がある。リスナーの気が散るようなものであってはならないが、退屈なようなものであってもならない。ほとんどのミュージシャンが気が狂いそうになると考えられるようなことが、特に難しかったところだ。」 このアルバム「Music to Code By」は、Kickstarterで資金を調達して制作されたもので、25分のインストゥルメンタル曲が3曲収録されている。価格はCD版が20ドル、MP3版が18ドル。皆さんがコー
Javaで書かれたソースコードの大部分は冗長？ | スラド デベロッパー
本家SlashdotでYour Java Code Is Mostly Fluff、New Research Finds（あなたのJavaコードの大半は無駄なもの、新たな研究で判明）なる記事が出ている。元ネタはITworld。 さらにその元ネタの論文を見ないとなかなか意味が把握しにくいのだが、自然言語による文章解析をプログラムコードにも適用したところ、そのような結果が得られたという話のようだ。 自然言語で書かれた文章は、その一部の単語がなくなったとしても意味を把握できることが多い。このように文中でなくなっても意味が変わらない単語を「chaff」（もみ殻）と呼び、逆にその単語がなくなると意味が分からなくなる/意味が変わってしまう単語は「wheat」（小麦）と呼ぶという。自然言語でこのような「chaff」と「wheat」を抽出する手法をプログラミング言語にも応用してJavaソースコードを分析し
C言語の開発者によるgoto文の使い方を対象とした実証研究の結果、「goto文は無害だと考えられる」 | スラド デベロッパー
Edsger Dijkstra氏がgoto文の危険性を主張したのは1968年。それから50年近く経過した現在もgoto文は使われ続けているが、Dijkstra氏が懸念したようなgoto文の無制限な使用が行われているのかどうかという点や、それがバグの原因となるような有害なものなのかどうかといった点については、よくわかっていなかったという。こういった点に関する実証研究が本家/.で紹介されている。 本家/.「Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"」より 200万近いC言語のファイルと1万1千件を超えるプロジェクトからランダムに抽出した統計的に有効なサンプルを質的および量的に分析したところ、開発者はほとんどの場合gotoの使用を適切に制限しており、Dijkstra氏が懸念したような無制限な使用は行わ
絶滅しそうなプログラミング言語は？ | スラド デベロッパー
新しいプログラミング言語が人気を得ると、古いプログラミング言語は人気を失いつつも使われ続けるか、死んでいくことになる。Dice Newsの記事では、死んでいくと予想される5つのプログラミング言語を、最後に書くプログラム「Goodbye, World」のサンプルコードとともに紹介している。 本家/.「Goodbye, World? 5 Languages That Might Not Be Long For This World」より 死んだテクノロジーのゴミ箱行きになると予想されるのは、どのプログラミング言語だろうか。Perl 6の開発状況を考えると、Perlは素晴らしい候補者だ。Perl 6は言語の完全な刷新を目指して2000年に設計が始められたものの、開発は遅々として進んでいない。RubyやVisual Basic .NET、Object Pascalは一時的に人気を獲得したが、死んで
プログラミング言語がソフトウェアの品質に与える影響 | スラド デベロッパー
あるプログラミング言語がその仕事に適したものであるかといった議論は論争に発展しがちだ。時には宗教戦争の様相を呈することがあるものの、プログラミング言語がコーディングプロセスだけでなく完成した製品の特性にも影響することは多くの方が同意するところだろう。これについてカリフォルニア大学デイビス校のコンピューターサイエンス研究者らが、プログラミング言語のソフトウェア品質に与える影響(PDF)に関する調査結果を発表した。研究ではGitHubの729プロジェクト(17言語、29,000人が書いた8,000万行のソースコード、150万コミット)を分析。大きなサンプルサイズを利して混合研究法のアプローチをとり、複数の回帰的モデリングやテキスト解析を組み合わせて静的型付けと動的型付け、型付けの強弱といったプログラミング言語の特徴がソフトウェアの品質に与える影響を調べた。異なる手法による調査結果を組み合わせ、
スラッシュドット ジャパン | 大規模なソースコード、何万行までいじれますか?
Kachi曰く、"サンのWebページ「Sun&Users」に筑波大学の加藤和彦教授のインタビューが掲載されている。この中で、『数は少ないんですけれど、大規模なソフトウェアを我々の想像を超えていじっちゃう人たちが現れてます。(中略)…昔よりも、ソフトの生産性は上がっているんですね。(中略)…最近の若い人の非常に生産性の高い人は、1万行なんて割と軽々越えるんですね。1万行、3万行は、全然苦にしない。10万行でも苦にしない。』と発言している。 さて、あなたは、どのくらいのソースコードに立ち向かうことができるだろうか。ちなみに投稿者は、アマチュアなので万年Hello worldどまり。"
同僚の書く酷いコード、どうやって気づかせる？ | スラド デベロッパー
私の同僚は非常に頭がよく、ソフトウェアの知識も豊富だが、想像を絶するほどひどいコードを書く。たとえば、 すべてのプログラムは1つの関数に詰め込まれ、際限ない繰り返しのせいで無駄に引き伸ばされている 変数名やクラス名から得られる情報は泣きたくなるほど少ない コードを短く、読みやすくするための基本的な言語機能は無視されている オブジェクト指向プログラミングの虐待は吐き気を催すほどで、戦争犯罪レベルといえる しかし、彼は私が生まれる前からプログラミングをしており、非常に頭が良いことで、人の意見に耳を貸そうとしない。そのため、「この関数をこのように書いたら良くなると思いませんか」といった簡単な提案は受け入れられないだろう。彼に事実を伝え、良いコードと悪いコードの区別をわかってもらうにはどうすればいいだろうか。
/.Jに聞け：コメントにおける変なルールって？ | スラド デベロッパー
ブログ「日々常々」で、「変更前をコメントアウトして残す」というバカバカしい習慣が紹介されている。 例として挙げられているのは、「コメントを削除する場合その旨をコメントとして残す」という例。 // 2012/08/15 irof 修正開始 //// 2012/07/21 削除開始 //// // 間違ったコメント //// 2012/07/21 削除終了 // 2012/07/21 irof 削除開始 // // 間違ったコメント // 2012/07/21 irof 削除終了 // 2012/08/15 irof 修正終了 someMethod(arg);
プログラマに対するひどい指示・ルールについて語ろう | スラド デベロッパー
とあるプログラマが「派遣時代に行った酷い現場の思い出」を togetter でまとめた「派遣 PG 時代の思い出」が話題になっている。曰く、 「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われた。前任者が「コードを共通化してください」という言葉を勘違いし、一つの画面クラスに全ての画面の機能を持たせ、メソッドの引数でどの画面として動くかを切り替えるという凄まじい実装だった。帳票 1 枚ごとに 3000 行クラスが書かれていた。など、恐ろしい話がたくさん並んでいる。/.J でもひどいコードについての話題は数多くあったような気がするが、みなさんが体験したもっとも「これはひどい」という話はなんだろうか ?
東証曰く、システム開発においてコーディング後にはドキュメントは不要 | スラド デベロッパー
2005年に発生した、「ジェイコム株大量誤発注事件」はみずほ証券に大きな損害を与えた。みずほ証券はこの損害の原因の1つに東証の売買システムのバグがあるとして、東京証券取引所（東証）に対し賠償を求める裁判を起こしていたのだが、この裁判が3月18日に結審した（日経ITpro）。これを受けて、日経コンピュータが「みずほ証券-東証裁判の争点を洗い出す」として争点をまとめている。 ここで興味深いのは、東証の開発手法やソースコードに対する姿勢だ。東証はソースコードの修正時にそれに対応するドキュメントの修正を行っていなかったそうなのだが、これについて「コーディングが終了した後はドキュメントは不要」と主張している。いっぽうのみずほ側はこれについて「ソフトウェア工学の知見を無視する暴論だ」として、重大な過失であると主張している。 また、ソースコードには著しい重複があったことが判明しているのだが、これについて
70～80年代のCOBOLシステムを支えたプログラマの引退が近づいているが、システムは動き続ける | スラド デベロッパー
1980年代には「COBOLは衰退するので、ほかのプログラミング言語に移行しなければならない」などと言われた。実際に1970～1990年代に書かれた細かなCOBOLプログラムのほとんどは新しいシステムと新しい技術に置き換えられている。しかし、銀行、保険会社、製造業、小売チェーン、医療機関といった大企業のミッションクリティカルなシステムは依然として大昔にCOBOLで書かれたコードによって運営されている。多くの企業はこれらのシステムを何度も入れ替えようとしたが、システムが全体が巨大で複雑な上、重要なビジネス・プロセスに統合されていること、また問題なく動いていることからこうした取り組みの多くは失敗した。 ITWORLDの記事によると、こうしたCOBOLで書かれたシステムを支えてきた団塊世代プログラマの引退が近づいているという（ITWORLD、本家/.）。 今は大学のプログラム講座などでは教えるこ
オライリーのLisp本「Land of Lisp」の表紙動物が名状しがたいものだと話題に | スラド デベロッパー
技術書籍出版社オライリーの書籍は表紙にリアルな動物のイラストが描かれているのが特徴だが、2月下旬に出版されるLisp本「Land of Lisp」の表紙に描かれている動物がリアルなイラストでは無く、むしろ動物とも言いがたい謎の生命体らしきものであることが一部で話題だ（オライリーの書籍紹介ページ）。 一見デフォルメされた象のようにも見えるのだが、目は四つあるし体色は緑だし鼻らしきものの先には手が付いていて「LISP」と書かれた旗を握っている。どうみても地球のものではない。やはりLispは変態なのか。 ちなみに、オライリーでのLisp本は現在これ以外に発売されていない模様。本家O'reillyでも、Lispだけを扱った本はこのLand of Lispのみのようだ。というか本家の表紙はどうみてもプログラミング本ではない。O'reillyでは過去Lisp本の企画があったようだが、著者が体調を崩して
いいコーディング規約、悪いコーディング規約？ | スラド デベロッパー
本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。 可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか？ ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか？ /.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか？ 逆に規約のせいで問題が起きてしまったケースなどあるだろうか？ 他にも、使える「自分ルール」などもあれば是非。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さようならsearch.cpan.org | スラド デベロッパー
今まで見た中で最もひどいDBのテーブル設計は？ | スラド デベロッパー