OracleとGoogleのJava著作権侵犯裁判の現状を知る（2018年版） - orangeitems’s diary
控訴審でOracleがGoogleに勝利 Oracleが、Googleに対してここ8年間に渡ってJavaをめぐり約1兆円以上の損害賠償を求めている裁判が行われているのをご存じでしょうか。かの有名なAndroidは一部、Java APIが利用されているのですが、その中で著作権侵害があったとの訴えです。 米国時間で2018/3/27にOracleがGoogleに勝利したというニュースが舞い込みました。 jp.techcrunch.com 火曜日（米国時間3/27）に連邦控訴裁がこの訴訟に新しい命を吹き込み、GoogleがOracleのJava APIsを使ってモバイルオペレーティングシステムAndroidを作ったことは著作権法の侵犯にあたる、と裁定した。 とはいえ、経緯を知らない人にとっては何のことやらわからない記事だと思いますので、短時間で理解できるようにまとめてみたいと思います。 賠償金額
新卒から12年エンジニアとして勤めた某外資証券会社を辞めてスタートアップにジョインした話 - itohiro73’s blog
本記事は退職者その2 Advent Calendar 2017の25日目の記事です。 adventar.org 僭越ながら最終日を担当させていただきます、@itohiro73 と申します、よろしくお願いします。 半年前ちょっと前にすでに入社エントリーは書いているので順序が大幅に逆になってしまっていますが、今回は退職者アドベントカレンダーということで、せっかくの機会なので新卒から12年も勤めた前の会社のことを振り返ってみようと思います。 前の会社について 世界的にもかなり大きい外資系証券会社でエンジニアとして新卒から入社して12年と1ヶ月半くらい勤めました。会社名に関しては、自分がかなり大々的にOSS活動等もしていたこともあり公開情報からちょっと調べればわかるところではありますし、本記事を読んで明らかにわかる部分もあります。とくに隠しているわけではないのですが、一応大人の事情としてあえて言及
ORMは不快なアンチパターン | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
チケット管理のアンチパターンとベストプラクティス
主語がでかいタイトルですが、自分なりに考えようという目的です。 自分の思考の整理。 何か意見があればガンガンコメントなりツイートなりして欲しい。 前提として、 チケット管理システムは２つぐらいしか使ったことがないので、そちらに偏ってしまうかも。 ちなみにRedmineとBacklog。 （今がRedmineだから多分それに偏る気が） アンチパターン アンチパターンというのかは分からないけど 今まで困ったこと、やりにくいと感じたこと、ダメだこりゃ、と思ったこと。 ・運用フローが複雑 フローが複雑だと途端に人は面倒になる。なるべく抜け道を探し秩序が乱れる。 抜け道が見つかると割れ窓理論とかいうやつで、どんどんぐちゃぐちゃになる。 誰もフローに乗ってくれない状態になる。 ・使われていない項目がある なぜあるのかわからない項目。重要そうだけど埋めなくても良い項目。 誰かが埋めてくれるだろう、他の人
SonarQubeのQuality Gatesの設定値を考えてみた
ソース静的解析ツール「SonarQube」は「Quality Gates」という、コードレベルの品質基準を設定できます。ただ、どういった値を設定すればいいか？ 悩ましいところなのでいろいろ調べて自分なりの基準を考えてみました。 Quality Gatesの魅力 Quality Gatesの魅力。それはずばり、基準値ができることだと思います。SonarQubeによってソースコードレベルで解析が行われ、コードカバレッジ、ソースの重複度、複雑さといったデータがわかるようになれば、次はそのデータをどう扱うかがポイントになるはずです。 周囲でSonarが流行っていたときに感じたのですが、解析結果がグラフィカルに確認できるようになったのに、「で、どうしようか？」と困っている雰囲気がありました。確かに、「Complexity 8.2」って言われても、それがいいのかわるいのかよくわからない。 だから、得た
Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
マルチリソース、マルチテナントに対応したDBマイグレーションツール「solidbase」1.0.0をリリースしました - たけぞう瀕死ブログ
Javaベースのデータベースマイグレーションツールsolidbase 1.0.0をリリースしました。 github.com これは元々GitBucketで使用するために開発したものです。GitBucketではこれまで独自に実装した簡易的なマイグレーションシステムを使用していたのですが、外部データベースの対応やプラグインシステムの導入などに伴ってより汎用的なマイグレーションツールへの移行を検討していました。 Javaで利用可能なデータベースマイグレーションツールにはFlywayやLiquibaseなどがありますが、以下のような要件をすべて満たすものがありませんでした。 データベースだけでなく他のリソースも扱うことができる（任意のマイグレーション処理を実行したい） 1つの定義で異なるDBに対応する（デフォルトのH2だけでなくMySQLやPostgreSQLなどにも1つの定義で対応したい） マル
２年前に転職しました
退職しましたというエントリを書いてから早くも２年、そして、１年前に転職しましたというエントリを書いてから１年が経過しました。せっかくなので、またまた１年を振り返ってみることにします。 いままであらすじ ２年前、ごく小規模の WEB 受託開発会社から、中規模の広告代理店へ転職。 転職先では、エンジニアの社員はわしだけ。 「エンジニアの居ない場所に行ってポストを作れさえすれば、割と無双できます」は、やはり正しかったと自負。 よかったこと ２年目は内製体制への慣れが出てきて、チームの雰囲気が変わってきました。最初の１年では、外注のクセが抜けておらず、何かをやりたいときにチーム内のエンジニア（わし）に「発注」するようなコミュニケーションになっていました。そのため、何をするにも「発注者」が「要件」「仕様」を決めてから「発注」という流れになり「発注」まで長い時間がかかった上に「発注」後に「仕様」が変わ
Scalaはなぜ難しいと言われるのか？ - たけぞう瀕死ブログ
Scalaをどうやって学ぶのがいいのか？ということはScalaを使い始めた数年前からずっと考えています。よく「Scalaは難しい」と言われますが、 どこが難しいのか？ なぜ難しいのか？ ということを、これまで書籍や雑誌記事、ハンズオンなど入門用のコンテンツを作ってきた経験を踏まえて整理してみました。 まず、Scalaが難しいといわれる理由のひとつに学ばなくてはならないものが多すぎるという点があげられます。Scalaはオブジェクト指向言語ですが、関数型言語の特徴的な機能を取り入れているため、きちんと理解するには両方の言語のイディオムを学ぶ必要があるためです。 ただ、Scala自体は必ずしも関数型言語の知識がなくても使えるように設計されています。最初はBetter Javaとして一般的な手続き型オブジェクト指向言語の延長として使い始めることができ、Scalaの特徴的な機能に触れていくことで少し
沈没船エントリのあとがき
http://anond.hatelabo.jp/20130310152356 沈没船エントリを書いた増田です。 およそブログ向きではない冗長で読みにくい文章だったけれど、 元増田に便乗したお陰か、思ったより多くの方に読んで頂けたようでとても嬉しいです。 こんな付け足しを書くのは興ざめかもしれないけれど、 似たような境遇の人も多いようだし、 PG・SEの現場に20歳から10年居続けてきた人間として、 もうちょっと具体的な事を「あとがき」として補足しても良いかな、 という気になりました。 （申し訳ないことに、この付け足しも長いです） 私の文章は、元増田 「上流エンジニアなんて死んじまえ」 http://anond.hatelabo.jp/20130309233920 のブクマやトラバで言われている 「上流にも技術力はあるはず」 「下流だってダメな奴が多い」 という、上流下流のどちらが優秀かと
Optionalの取り扱いかた - 日々常々
JavaSE8で追加されたjava.util.Optionalにはnullとの戦いに終止符を打ってもらいたいと思っているんですが、思ってるだけだと何も起こらないので、使い方とか思ったこととかを一通り書いておきます。 Optionalのファクトリメソッド Optionalのインスタンスメソッド 値を取得するもの 値を使用するもの Optionalのまま扱うもの まとめ なお、一通りと言いつつOptionalIntとかはスルーしています。機会と書くことがあればそのうち書くかもしれません。 Optionalについては諸事情（遅筆とか理解不足とか分量とか）によりJavaエンジニア養成読本では軽い紹介にとどまっておりましたので、補足としてお読みいただけると幸いです。あと、この辺も参考にどうぞ。 OptionalのJavadoc 一通り触って適当にコメント書いたコード(GitHub/sandbox)
Eclipseデバッガ徹底解説 - Yamashiro0217の日記
Java Advent Calendar -ja 2010 : ATND 11日目。昨日は、id:daisuke-m でした。 完全に Eclipse のこと書けとふられてる感じがしたので Eclipse について書く。 Eclipse の何について書こうかと考えたんだけど、先日、社会人になってからプログラム書き始めた弊社の若い子が、「デバッガ」の存在を知らなかったのでデバッガの基本的な使い方などについて書く。 PHPというちょっとしたWebページをさらっと書くには素晴らしい言語だけしか知らないみたいだから、あんまりデバッガ使う文化が無かった模様です。 var_dumpデバッグェ…。 今回は初心者向け記事なので、基本Java使い倒してる皆様は読まなくてよろしいが、Break Point Properties の Condition とかDrop To FrameとかExpressionの機
Java漬けになってきたが、それでも僕は書いてない - 無駄かもしれない足掻き
4月8日にJava Day Tokyo,11日にJJUG CCC 2015 SpringとJavaの大きなイベントが続けてあって、どちらも朝から懇親会まで参加してきた。 Java Day Tokyo Pepperとかミニカーとか車とか、ありとあらゆるものがJavaで動いていた。 Java9は来年リリースするらしい。 ハンズオンではじめてラムダ式とStreamAPIの書き方がわかった。 JJUG会長の鈴木さんにDukeのもにもにをいただいた(家宝) みんなでJavaの20周年を祝ってケーキを食べた JJUG CCC 2015 Spring Javaでコーヒーを入れたりミニカー？を動かしたり3Dプリンタを制御したりしてた GroovyでExcel操作が簡単にできることを知った nullを制御するための考え方を知った 払えるならお金を出しておいたほうがいいことも知った 飛び入りLTは時間が短くな
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
代替言語について思うこと。 - nobkzのブログ
さて、Qiitaにこのような記事が書かれてました。 Java 代替言語が普及しないこれだけの理由 - Qiita この記事に関して、僕は、言語マニアとして、Javaの代替言語だけでは無く、C#、JS、Erlangなどの、他の言語の代替え言語をいろいろ使っており、それに関して思うことがいろいろあるので書きます。 ちなみに僕はQiitaのアカウントは持っているけれども、このような記事は技術tipsよりも、エッセイに近いと思ったので、はてなブログに書きました。 代替言語について思うこと 代替言語とは まず、ここで言う「代替言語」というのを簡単にどういうものかを簡単に定義してみると、「ソースコードや 実行可能な形式にコンパイルするなどを通して、既存の言語プラットフォームで動作する、その言語とは異なる言語のこと」みたいな感じでしょうか。ちょっと、なんか上手く表現できませんが。 たとえば、Javaで言
静的コード解析でコードの改善を行う - 水まんじゅう2
コードレビューはしたことがあるでしょうか。 変なコードを書いていないかを確認するためにだれかにコードを確認してもらうという事はよくやります。 誰かにコードを見てもらえるのが一番良いのですが、その誰かがいない場合、機械的にコードを解析して変なところがないかを確認してもらうことが出来ます。 それが静的コード解析です。 Javaでは多くの静的コード解析ツールがあり、多くは無償で利用することが出来ます。 今回はそのうちのFindBugsとPMDを利用して静的コード解析をしてみたいと思います。 FindBugs FindBugsはコンパイルされたバイナリを解析し、不具合を検出してくれます。 例えば、 if("str" == "str")〜〜 という書き方は良くなく、Javaでは以下のように記載する必要があります。 f("str".equals("str"))〜〜 こういった問題点を検出してくれます。
Java 8とScala ‐アプローチの違いと相互イノベーション | POSTD
ScalaとJava 8に関する プレゼンテーション が、他の似た内容のものよりも多くリツイートされ、大変うれしく思います。だから、こうして皆さんにブログでも書いてお伝えすることにしました。ScalaとJavaとの違いと、それぞれの重要性についてお話しします。両者は相互にイノベーションしています。言語間でお互いに取り入れています。では、Javaが使える場合であっても、Scalaを学ぶ必要があるのでしょうか？ もちろんです。より多くの言語を知れば知るほど、あなたはさらにプロフェッショナルになっていきます。 もし、ScalaエンジニアにScalaとJavaとの基本的な違いについて尋ねたとしても、おそらくその人はラムダ関数とトレイトに関する違いを全て言うことはないでしょう。代わりに次のような例を出すはずです。 public class Person { private String firstN
綺麗な言葉で話しかけても糞コードは糞コード - カレーなる辛口Javaな加齢日記
「クソコードと呼ばない」http://ppworks.hatenablog.jp/entry/2015/01/17/152545 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 語るに落ちた．orz 精神論じゃコードは解決しないよ． 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。 これは「今では糞コードになったがかつては意味のあったコード」や「完璧ではないが十分に優れたコード」の話だよね． それはまだ幸運な人達の話．*1 世の中には生まれた時から何も価値を提供してこなかった，想像を絶する真の糞コードと言う物が存在するのだ．技術的負債って言葉も聞いたことないのかな． 改訂新版 Cプログラミング診
ベンダーロックイン排除のためにオープンという議論 - Nothing ventured, nothing gained.
自治体などの入札においてベンダーロックインを避けるため、特定のベンダーや技術に縛られないようにする。最近、このような方針を掲げる自治体や団体も出始めている。 これ自体は良い方針だが、ここで考えなければならないのが、何をもってオープンとするかである。 Web系であれば、利用者の多いLinuxのディストリビューションにApacheとMySQL、それにPHPやJavaのフレームワークを使うということになるのだろうか。ここのApacheはnginxでも良いし、MySQLはPostgreSQLでも良い。フレームワークもあくまでも例なので正直オープンであればなんでも構わない。 だが、この「なんでも構わない」の部分を明確にしておかないと、実際に調達を行う場合、入札仕様書（RFP: Request For Proposal）が書けないので、どっかでオープンの定義を明確にしないといけない。 その定義の難しさ
項目16 「継承よりコンポジションを選ぶ」: 柴田 芳樹 (Yoshiki Shibata)
Effective Java 第2版 (The Java Series) 作者: Joshua Bloch出版社/メーカー: ピアソンエデュケーション発売日: 2008/11/27メディア: 単行本（ソフトカバー） 1990年代前半から中頃（？）までは、オブジェクト指向と言えば、継承というはやりがありました。特にC++ではインタフェースの概念が言語仕様上なく、すべてをクラスの継承で表現しなければなりませんでした。その結果、すべてを継承で設計し、いわゆる差分プログラミングが良いという考えもあったりしました。 項目16 「継承よりコンポジションを選ぶ」では、次のように述べられています。 メソッド呼び出しと異なり、継承はカプセル化を破ります[Snyder86] 。言い換えれば、サブクラス は適切に機能するために、スーパークラスの実装の詳細に依存します。スーパークラスの実装はリリー スごとに変更さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
