「jdk」を含む日記 RSS

はてなキーワード: jdkとは

2024-03-06

anond:20240306135302

すげーわかる

ファルコムって空の軌跡も神キャラデザぶっこわしてリメイクしたりしたし、なんかそのへんのセンスねーよな

サウンドも昔のjdkの方がよかったわ・・・・。未だにツヴァイ!とかぐるみんサントラ聞いてるぜ。

フェルガナの誓いも最高だったなぁ・・・

2022-12-14

低い、安い、まずい、リモートワーク環境

エアコンのない 4畳半の物置部屋でホームページを作ったり、 Excel でまとめたり、 メールしたりして生活している。 寝袋にくるまったり、 湯たんぽ身体の随所に這わせながら暖をとる。 最近コワーキングスペースが近所にできたので、 そっちに行こうと思うが、 機密情報を見せつけて作業するのはどうかと思うので、なかなか踏み出せない。 エアコンのある台所には、テレビHDMI がくっついてるのでそっちで作業しようか考え中。

部屋の構造的に物置部屋にはエアコンが付けられない。 辛い。ただ、人間、気温には慣れるな。空調以外で何があれば便利だろう。2万出す。

机: 5000円くらいのニトリの机 縦幅を拾った板でかさ増し。 60→75×120cmもあるぜ。 ジャンボだぜ。

椅子: 15000円くらいのオカムラ椅子。 失敗できないので会社にあったのと同型のを楽天中古屋で買う。 4000円のニトリ椅子に座ってたら腰が痛すぎた。

無線LAN: ケーブルテレビデフォルトルーター、地味に電波が届かず、リピーターで中継入れてるが、時々切れる。

パソコン : 支給ノートパソコン (メモリ 8GB、 人権が保ててる)。 電源の調子が悪い。

モニター : 実家でもらった 23インチ10選手モニター+社内でモニター入れ替えの時にもらった 23インチ流行りのクラムシェルだぜ。 いつ壊れるかヒヤヒヤしてるぜ。

カメラ : 2000円でアマゾンで売ってた Web カメラ。 妙に明るく映る嫌な奴。

キーボード: メルカリ奇跡的に 1000円で買えた、 Sun microsystemsキーボード (新品)。 おまけで java 1.1 の jdk がくっついてきた。 アプレット作るぞ。

マウス : 腱鞘炎になり、 3500円でトラックボール買った。 ボタンがたくさんあるので使いやすい。

イヤホン : メルカリで 600円で買ったイヤホンラジオも聞いてる。 話すと声がくぐもるみたい。 はきはき喋れるようになった。

ノートペン: 時々出社するときに持って帰るぜ。

お役立ち : 100円で買ったコルクボード。 各種パスワード機密情報がむき出しだぜ。 バインダー100円で買った。 ノートをとるのに必須な役立ちアイテム

トータル: ¥30000弱。椅子が半額を超えてるぜ。

何を変えたらもっと快適になるんだ。 はてな諸氏、教えてくれ。2万出す。

2022-11-14

anond:20221113102558

ひとことで Java と言っても今と昔とは全然違う。

Java進化してるし、JVM動作する他の言語も増えて技術の幅は大きく広がった。

今は OSSJDK が乱立していて、そのどれを使って開発すべきか決断することも一つのノウハウとして必要

他にも今なら DevOps のために自動ビルドデプロイの仕組みから設計していく必要がある。

まともな会社ならそろそろ Javaコンテナ運用する流れになってきてるからマイクロサービス的な設計意識する必要があるし、暖気運転不要Java 実行環境なども考えて作っていく必要がある。

これだけできれば、他の言語に行ってもキャッチアップできるよ。

逆に10年前と同じことやってるようじゃ、どこに行ってもダメ

2021-09-22

anond:20210922200042

Sunの頃からJavaの延長サポートを含む商用サポート有償で今より高かったのにな。 https://atmarkit.itmedia.co.jp/ad/sun/0810javaseforb/0810javaseforb.html

無償しか知らん・使わん貧乏ユーザさんが多かったのでしょ。

そしてOracle JDK 17で再度ライセンスが変更され、Sun時代と同様に一定期間だけ無償になったら、それはそれで文句をいう訳だ。

anond:20210922192305

もともとOpenJDKがあることを知らない人が騒いでただけの印象。Oracle JDKの超高かった有償機能もOpenJDKに寄贈したのにね。

anond:20210921230951

Oracle JDK はもともと無償版と、テクニカルサポート付きの有償版があった。

Java11の際に、属に「有償化」と言われたのは、無償版を OpenJDK 移管して、 「Oracle JDK」は有償版だけが残った状態になったことをいう。

Oracle 自身無償Oracle OpenJDKリリースしていた。

この話にはもうひとつ LTS (Long Term Support : 長期サポート版) という要素があって、Java 9 以降、Java半年ごとの定期アップデートと、3年に1度の長期サポート版(3年サポート)という仕組みになったんだけども、Oracle無償版をOpenJDK移管して半年ごとのnon-LTS版しかさないと発表した。

無償版のLTSはサードパーティに任せたわけだが、当初、この無償LTSはどこがやるとも定まっておらず混乱が生じた。

後にいくつかのサードパーティ無償LTSを発表して混乱が収まったわけだが、この時に「有償化!」と騒ぎ立てたニュースが、普段Javaを使わない層には強烈な印象となって残ることになった。

この間ずっとJava無償で使うことができたが、センセーショナル煽りたがるインフルエンサーは「そのうち有償化する!やめた方がいい!」と煽り続けて今に至る。

2021-09-21

Javaを救うOracleレジスタンス

悪の帝国 OracleJava有償化し重税を課そうとしたその時、正義勇者 Amazon が立ち上がり新しい Java 実装 Corretto を無償で広めて救ったのだ!

……という情弱が好きそうなデマがあるんだが、こんな陳腐シナリオに喜んでいるようではインチキテックYouTuber に食い物にされてしまうぞ☆

Oracle レジスタンスはいた。彼らは Oracle の中に潜んでいたんだ。

赤字に苦しむ Sun

時は2005年に遡る。

Java を開発した 米 Sun Microsystems は赤字にあえいでいた。

2004年Java 5 (目玉機能ジェネリクス) がリリースされてしばらくの頃だ。

この頃、ひとつオープンソースプロジェクトが立ち上がる。名を Apache Harmony という。

開発は2005年5月に開始され、2006年10月には Apache 財団トップレベルプロジェクトとなった。

Java は当初より、 Sun の独占物ではなかった。

Sun は多数の企業をまきこみ、いろんな企業Javaライセンスしていた。

Java実装Sun が持っていたが、各社が独自実装したり、Sun契約してコード提供を受けたりしていた。

Java を名乗るためには Technology Compatibility Kit (TCK) という互換チェックをパスしなければならない。

初期の Javaオープンソースではなかった。誰もが自由コードを参照し用いることができるものではなかったんだ。

Javaオープンソース化を目論んだ Apache Harmony

これをオープンソース化しようという野心で始まったのが Apache Harmony プロジェクトだ。

Java実装をいちから書き起こしオープンソース代表的Apache License Version 2 ライセンス提供したのだ。

しかし、SunApache2 ライセンスを良しとせず、Harmony に Technology Compatibility Kit (TCK) を受けさせなかった。

Java を名乗らせなかったということだ。

なるほど。彼らが Javaオープンソース化したレジスタンスだったわけか?

違う。話はそんなにシンプルではない。

OpenJDK の登場

2006年 SunJavaオープンソースにする意志があると発表した。

SunJavaリンク例外付きの GNU General Public License でオープンソース化することにした。

これが OpenJDK である

Harmonyライセンス自由な改変を認めるものだった。

OpenJDKライセンス派生物を作ったなら、そのソースコードの公開義務がある、という点が大きな違いだった。

OpenJDK は出た当初はまだ SunJDK との非互換が多かった。しかしこれが現代まで続く OpenJDK の始まりだったのである

2007年11月 GoogleAndroidを発表した。 AndroidJava 言語で開発することができる。

そのベースとなったのは Sun との火種くすぶる Apache Harmony だった。よりにもよって!

これは揉めに揉め、巨額な賠償金をめぐる裁判となる。

(後にGoogleが負けて賠償し、現在Android は OpenJDK ベース)

Sun の身売り

その渦中、赤字に喘いでいた Sun はついに身売りを決断する。2009年のことである

当初 IBM との交渉が報じられていたが金額で折り合わなかったようだ。

そこに颯爽とあらわれたのが Oracle であるOracleSun Microsystems を買収することになった。

しかOracle にはよくない噂がある。敵対買収してプロダクトを潰してしまうという黒い噂だ。

SunJavaOracle に食い物にされてしまうんじゃないか、いわゆる 「悪のOracle」 のイメージはこの頃からのものだ。

しかし、 Sun はすでに Javaオープンソース化していた。 派生物もオープンソースにしなくてはならない OpenJDK で!

OracleJavaSun 社ごと買ったが、 Java はすでに独り占めできるようなものではなかった。

Java オープン化の仕上げ

時は流れ、2018年 Java 11リリースされる。

Sun 本家JDK を引き継いだ Oracle JDK と、OpenJDKがついに統合される。

Oracleソースコードを OpenJDK に寄贈し、 Oracle JDK も OpenJDK ベースとなった。

ここに OpenJDK への移管は完全となり、Javaオープン化は成就した。

それまでの OpenJDKOracle JDK との非互換不安視されていたわけだが、Java11 からはその不安もなくなった。

こうして完全にオープン化された Java は、各サードパーティーからディストリビューションが出るようになった。

Java11 での Javaオープン化を経て、Javaディストリビューション乱立時代へと突入する。

Amazon Corretto もそうした OpenJDK派生ディストリビューションひとつである

OpenJDK の開発は今なお Oracle が主力となって牽引している。

レジスタンス

Java解放しようとしたレジスタンスは、赤字に喘いでいたSunの中にいた。

たとえ Sun が身売りをすることになろうとも、Java邪悪独裁者の手に渡さないように。

Sun が倒れてしまう前に Javaオープン化された。Java仕様策定Java Community Process (JCP) にて行われる。

Java仕様策定Oracle独断で進めることはできない。 OpenJDK の開発も Oracle独断ですることができない。

GNU General Public License でオープンソース化された Java は、派生物のライセンスGPL強制されソースコードを公開しなければならない。

未来永劫、Javaオープンソースでありつづける。

そんな OpenJDKリリースした、当時の Sun中の人達こそがレジスタンスだったんだ。

Oracle はそんな Java を、そういう存在だと分かって Sun ごと買った。

Sun中の人達の多くは Oracle へと移籍した。そして、今でもオープン化された Java を作り続けている。

2020-11-20

anond:20201120120157

ほんとに初期の初期はJDKインストールだけしてコマンドラインハローワールドから始めて継承ぐらいまでやっといたほうがよくない?

IDEプログラミングの何を楽にしてくれてんのかが理解出来ないとプログラム勉強じゃなくてeclipse勉強に終始しちゃう気がする

2019-11-25

anond:20191125164936

これ好き

平成教師「んだhdけけjdじえねいdおえkwっjdkあぁぁ!?

虐待おじさんの裏返った声で脳内再生された

2019-11-06

Javaってやっぱり終わってね?

そう言うとシュババババッって謎の勢力がやってきて

無料JDKもある!OpenJDK!!」などと早口でまくし立てていくのだけれど

JDKじゃねえよ

エンドユーザーJREはどうやって更新してくんだよ

アプリに同梱しろ」ってLTSが終わるまでセキュリティパッチの子守りしていく金ユーザが払ってくれるのかよ無理だろ

2019-04-18

Oracle JDK有償化について

https://forest.watch.impress.co.jp/docs/news/1180607.html

Oracle JDK有償化すると困るのってOracle JDKで開発している人なの?

実行時はJREだけでいい場合費用不要なの?

これで困るのって、二次受け三次受けでJDK使って開発している請負会社になるの?

教えてはてな民

2018-11-16

Java界隈はまた一私企業の打算に乗り換えて船出するらしい

Sun MicrosystemsOracleと一私企業の打算に乗っかり、彼らのリソースを食い潰してグズグズ文句たれて、Oracleギブアップして捨てられそうになって悲鳴を上げてたら、ギリギリになって乗り換え先の打算が見つかって大喝采

オープンソースJDKは既にあるのにそれを自分たちメンテしながら一私企業方針転換に振り回されない仕組み作りを作る方向には全然かわない。

どこまで行ってもプロプライエタリ文化がこびりついてる世界なんだな、Java界隈って。

2018-06-10

anond:20180610112757

JDK「ずっとフリーだったけど、いい歳になったのでOracle結婚しました」

2016-07-28

http://anond.hatelabo.jp/20160728113742

突っ込まれるとは思ってたけどjarsignerはJDK付属するjar署名ツールのことで、

遭遇したエラーの原因にAndroid関係ない。JDK問題

http://anond.hatelabo.jp/20160727175406

ライブラリバージョンが一致しているかどうか確認するのは当たり前のことだよ。

つーかNodeでもライブラリドキュメント読めば互換性があるかどうかはきちんと書いてある。

Javaは安定してるっていうけど、この前Android開発でJDKバージョンアップした時にjarsignerのデフォルト引数が変わっていてひどい目にあったかJavaでも同じ。

2015-11-12

参考訳:拡散したJavaシリアル化の脆弱性についてApache Commons声明

原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日:2015年11月12日(午後にタイトル日本語しました)

----

2015年11月1日 火曜日

Apache CommonsJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント

著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)

AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクトシリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータバイト列で吐き出すこと。シリアル化されたJava オブジェクトRMIなどのリモート通信プロトコル使用される。)を使用する際に任意Java関数の実行や操作されたバイトコードの挿入さえもを行う方法説明です。

Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereJBossJenkinsWebLogic、OpenNMSといった様々な製品調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオ記述しています

両者の調査活動は、開発者Javaオブジェクトシリアライゼーションに信頼を置きすぎていることを示しています認証前のシリアル化されていないオブジェクトにも。

Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効オブジェクトツリーだけを保証しています

不幸にも、型のチェックが起こるまでの間に既にプラットホームコードが生成されて、重要ロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者コントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまます脆弱性のあるアプリケーションクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルOSコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます

これに対する最も良い防御は、信頼されていないピア通信相手)とは複雑なシリアルプロトコルを使うことを避けることです。ホワイトリストアプローチ http://www.ibm.com/developerworks/library/se-lookahead/実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができますしかしながら、これは常にできることではなく、フレームワークアプリケーションサーバがエンドポイント提供しているような時にはできません。簡単な修正方法がなく、アプリケーションクライアントサーバプロトコルアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。

これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムSpringフレームワークApache Commons コレクションからクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性エクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日攻撃者が簡単に得られるチェーンです。

(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c

この脆弱性のために利用される(訳注:blamed)ことができない確かな機能実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的修正していくことが要求されますモグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。

Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能提供するかどうかです。

これには前例がありますOracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャー定義されているとデシリアライゼーションを拒否します。

これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできますApache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャー存在独立したこの機能無効化することを計画しています

しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンApache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。

このブログポストレビューのために Gabriel Lawrence に感謝したいと思います

Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラス提供する Java ライブラリです。InvokerTransformerコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェース実装の一つです。

一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]

コメント

OracleWeblogicセキュリティアラートを発行しています

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

提供されている回避策は、T3プロトコルへのアクセス(とリバースプロキシーにおけるT3メソッドフィルタリング)です。

2015-02-11

SpringBootアプリjavafxを使って配布しやすくしよう

概要

Javaで開発されたアプリケーションにはインストールにまつわる難点がある。

それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである

また、サーバーサイドアプリケーションJavaである場合デプロイ監視の際の難点が多く運用者を悩ませてきた。

javafxで導入されたパッケージャを用いることで各OSネイティブインストーラーの作成が可能になり、この問題を解消・緩和できる。

SpringBoot などを用いた ExecutableJar作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるものパッケージングできる。

問題点の整理

Javaで開発されたアプリケーションの配布には以下の問題点がある。

解決方法として

javafx-maven-pluginを使うとよい。javafxと冠しているが実態パッケージングツール

javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。

Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OSディストリビューション固有のパッケージングが行える。

公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。

実際にどのようにすればパッケージングできるか

まずアプリケーションmaven アプリとして開発する。

pom.xml に以下を追加する。

mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。

vendor適当組織や個人の名前を入れておきましょう。

※ 以下の XML が化けるのは増田不具合仕様っぽい。 http://anond.hatelabo.jp/20100205210805

<plugin>
  <groupId>com.zenjava</groupId>
  <artifactId>javafx-maven-plugin</artifactId>
  <version>8.1.2</version>
  <configuration>
    <mainClass>[main method class]</mainClass>
    <vendor>[Vendor Name]</vendor>
  </configuration>
</plugin>

あとはそのままビルドすればよい。

maven clean jfx:native

ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります

本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。

これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。

/opt/app-name/ の下には app と runtime の2つのディレクトリがあります

app の下にはビルドした jar ファイル依存ライブラリが置かれています

runtime の下には実行用の jre が配備されています

実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です)

課題

OS毎の注意点

2014-04-20

新卒技術研修1日目 なんでJavaを学ぶのか

今日から新卒研修技術研修が始まりました。初日Java(JDK)をMacインストールして、簡単なプログラムを書くことから始めます

さて、なんでJavaなのかと感じるかもしれません。Webに限らずスマートフォンマルチプラットフォーム開発にもJavaScriptが浸透し、RubyPython学生の間で人気があります

言語の深い井戸を掘ってほしいから

逆説的ですが個人的には、Java研修に選びながらも「Javaを覚えてほしいわけじゃないだよね」って思っています

習得して欲しいのはJavaのものではなく、どこまで言語の深いところまで掘り下げたのか。つまり「深さを探った経験」を得てほしいからです。

Java新卒研修に適しているのは、適度な深さと広がりがあるから。それも、C++ほど底が途方もなく見えない感じもなく、Rubyのようにあs(以下略

この「言語を深く探った経験」は、まとまった時間がないとなかなか掘り下げられなかったりします。配属されて仕事や成果を求められるようになると経験しづらい。興味本位アプリを作ることに没頭する学生時代にも経験しづらい。教授に多くのタスクをふられがちな院生時代にも経験しづらかったりします。

プログラミング言語を、深いところまで掘り下げる機会は、新卒研修の時期に適していると僕は思います。成果や責務に追われずに、プログラミング言語に没頭することが許されているからです。

深く掘り下げた結果、何が見えてくるか

Javaのもうひとつの側面は、個性があらわれやす言語だと僕は感じます。きれいに書けば人間性が感じられるほど美しく書けます。逆に雑に書けば、プログラマとしての伸びしろが良い感じに見えるくらい、未熟に書けます

Java新卒研修に適しているのは、適度に思考の深みを表現できるから。それも、C++ほど哲学的に難解になることもなく、Rubyのようにとr(以下略

ここは賛否両論ありますが、いずれにせよJavaで何ができるのかではなく、Javaを通してその人の可能性の何が見えるのかが大事になりますアプリを開発する新卒側と、人材を開発する人事側の、視点の違いもありましょうが

からこそ、Javaというプログラミング言語を通して、深く掘り下げる機会を大切にしてほしいと思いますそれからJavaを通して何を表現できるのか。プログラム設計という点から、いろいろチャレンジしてほしいなって思います

そうすれば、掘り下げた分だけ他の言語も、もっと深く短時間で掘り下げられるでしょう。

そうして、自分思想仕事に対する人間性を、プログラミングで伝えられるようになったら、きっと一人前のプログラマになるでしょうね。

2010-07-02

使用許諾

LinuxJDKインストールすると最初に使用許諾がズラズラと何ページも出てくるけどアレ読んでいる人間いるんだろうか?

英語ネイティブ外人でも読まねぇだろうなぁ。

クレジットカード持ってると時々「規約改定しました!」とかで極小の字がびっちりと書かれた規約集送ってくるけど

あれも読んでいるヤツいるの?

(ちなみに、試しに読んでみたら全体で2文字誤植があったケドw)

なんだかねぇ。

2010-04-22

Redmine 0.9.3をTomcat 6で実行する方法

結構苦労したので健忘録として。。

環境は以下のとおり

JDK, Tomcat, JRubyインストール済み

MySQLインストール
yum install mysql-server
MySQLの起動
/etc/init.d/mysqld start
MySQLの設定

rootパスワードなどを設定する

mysql_secure_installation
Rubyモジュールインストール

RubyGemsモジュールインストールする

jruby -S gem install rails
jruby -S gem install warbler
jruby -S gem install activerecord-jdbc-adapter
jruby -S gem install activerecord-jdbcmysql-adapter
jruby -S gem install jdbc-mysql
MySQLRedmineデータベースを作成
mysql -u root -p
mysql> create database redmine character set utf8;
mysql> grant all privileges on redmine.* to 'redmine'@'localhost' identified by 'redmine';
mysql> exit

(ここでは、パスワードredmineしているが自由に)

RedmineDB設定

(任意の場所にRedmine解凍して、解凍先のディレクトリに移動した後)

cp config/database.yml.example config/database.yml
vi config/database.yml

database.yml

production:
  adapter: jdbcmysql
  database: redmine
  host: localhost
  username: redmine
  password: redmine
  encoding: utf8

#development:
#
#
#test:
#
#

後のwarbleでのエラーを防ぐため、developmentとtestコメントアウト

DBへのデータ投入
jruby -S rake generate_session_store
jruby -S rake db:migrate RAILS_ENV=production
jruby -S rake load_default_data RAILS_ENV=production
起動確認

script/serverで起動し、http://localhost:3000 にアクセスして正常に動作するか確認する

jruby script/server -e production
production.rbの修正

Tomcatで動かしたときにログ出力するための設定をする

vi config/environments/production.rb
config.logger = Logger.new(config.log_path)
config.logger.level = Logger::INFO
warblerの設定

warble.rbを生成

jruby -S warble config

warble.rbを修正

vi config/warble.rb
  config.dirs = %w(app config lib log vendor tmp extra files lang)
  config.gems = ["jdbc-mysql", "activerecord-jdbcmysql-adapter", "activerecord-jdbc-adapter"]
  config.gems["rails"] = "2.3.5"
  config.gems["rack"] = "1.0.1"
  config.webxml.rails.env = "production"

warファイルを作成

jruby -S warble

できたwarファイルTomcatに配置して、Tomcatを起動する

mv redmine-0.9.3.war /usr/local/tomcat/webapps/redmine.war
/usr/local/tomcat/bin/startup.sh

warblerのバグ(?)でwarに入らないファイルコピーして入れる

cp vendor/gems/rubytree-0.5.2/.specification /usr/local/tomcat/webapps/redmine/WEB-INF/vendor/gems/rubytree-0.5.2

http://localhost:8080/redmine/ にアクセスしてインストールできたか確認して完了!

2009-07-26

「カッコをつけたコードはカッコわるいのか論争」だけど

http://el.jibun.atmarkit.co.jp/hidemi/2009/07/post-29fb.htmlプログラム系のニュースサイトでこれを見つけた。

http://b.hatena.ne.jp/entry/el.jibun.atmarkit.co.jp/hidemi/2009/07/post-29fb.htmlブックマークでもつける派が多い。

で、ソースを確認できる有名プロダクツ適当に選んで、波カッコが付けられているか確認してみると
カッコをつけるで統一されているのってeclipseくらいだけだった。

x linux
x git
x postgresql
x subversion
x firefox
x python
x apache
x vim
x ruby
x gimp
x OpenOffice
x jdkライブラリソース
o eclipse

実践でがりがりコードを書いている人は、そんなことは気にしないんだよね。

波かっこをつける・つけない論争に限った話じゃなくて、コーディングスタイルの議論全般で
で感じることだけど、手間のかかるスタイルを支持する人って
「いいコードを書くために手間を惜しまないのがプロだ」が
「手間をかかるのがいいスタイルだ」にすり替わっているんじゃないかって印象。

2008-05-13

GuiceSeasar2 を連携させてみたよ

[参考文献]

    S2 は、.dicon ファイルで定義をだいぶ簡略化できる。パフォーマンスはどうなんだろう。誰かテストしてくれいw

    app.dicon

    <?xml version="1.0" encoding="UTF-8" ?>

    <!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container 2.4//EN" "http://www.seasar.org/dtd/components24.dtd">

    <components namespace="client">

    <include path="hello.dicon" />

    <component class="org.seasar.guice.Client" />

    </components>

    hello.dicon

    <?xml version="1.0" encoding="UTF-8" ?>

    <!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container 2.4//EN"

    "http://www.seasar.org/dtd/components24.dtd">

    <components initializeOnCreate="false">

    <component class="org.seasar.guice.HelloServiceImpl" />

    </components>

    HelloService.java、HelloServiceImpl.java は、上記 ITPro と内容が同じなので省略。

    Module.java

    package org.seasar.guice;

    import org.seasar.framework.container.S2Container;

    import org.seasar.framework.container.SingletonS2Container;

    import org.seasar.framework.container.factory.S2ContainerFactory;

    import com.google.inject.AbstractModule;

    import com.google.inject.name.Names;

    public class Module extends AbstractModule {

    S2Container container = null;

    public Module(S2Container container){

    this.container = container;

    }

    @Override

    protected void configure() {

    bind(S2ContainerFactory.class).annotatedWith(Names.named(container.getPath()));

    bind(Client.class).toInstance(SingletonS2Container.getComponent(Client.class));

    }

    }

    Client.java

    package org.seasar.guice;

    public class Client {

    private HelloService helloService = null;

    public void setHelloService(HelloService helloService) {

    this.helloService = helloService;

    }

    public void execute() {

    helloService.sayHello();

    }

    }

    Main.java

    package org.seasar.guice;

    import org.seasar.framework.container.S2Container;

    import org.seasar.framework.container.factory.SingletonS2ContainerFactory;

    import com.google.inject.Guice;

    import com.google.inject.Injector;

    public class Main {

    private static final String PATH = ".\\app.dicon";

    public static void main(String[] args) {

    SingletonS2ContainerFactory.setConfigPath(PATH);

    SingletonS2ContainerFactory.init();

    S2Container container = SingletonS2ContainerFactory.getContainer();

    Module module = new Module(container);

    Injector injector = Guice.createInjector(module);

    Client client = injector.getInstance(Client.class);

    client.execute();

    }

    }

    実行結果

    java -cp ?? org.seasar.guice.Main

    2008/05/13 21:19:22 org.seasar.framework.log.Logger info

    情報: Running on [ENV]product, [DEPLOY MODE]Normal Mode

    Hello, world!

    実行環境JDK 7 (build 1.7.0-ea-b24)

    2008-02-15

    コーダークミが失言「35行超えるとメソッドが腐る」

    コーダークミ(25)が1日夜、先月29日放送のラジオ番組で「メソッドのステップ数が35を超えるとソースコードが腐る」と不適切発言をしたことについて公式ホームページで謝罪した。所属事務所には批判の声が相次ぎ、同社が深夜まで対応を協議した結果、新アルバムJDK 7 Project」のプロモーション活動を自粛する事態に発展した。

    失言があったのは、先月29日深夜1時から放送されたニッポン放送コーダークミのオールナイトエクセプション」。番組冒頭、コーダー男性マネジャー(31)のコーディングの話題に触れ「やっぱ35(行)超えると、ソースが腐ってくるんですね。ホントに! だから、できれば1つのメソッドは35行ぐらいに収めてほしい」と発言した。

    この発言に同局には、放送後からこの日夜までにメールで二十数件、電話で数件の苦情や問い合わせが寄せられた。番組が収録だったこともあり、同局もHPで「パーソナリティー、コーダークミの不適切な発言を放送しました。配慮を欠き、誤解を招く放送をしたことをおわびするとともに、深く反省します」と陳謝した。

    関係者によると、コーダーは「 LL ( Lightweight Language ) の楽しさを知って欲しい」というマネジャーへの愛情表現として発言したつもりだったが、現在は深く反省しているという。

     
    ログイン ユーザー登録
    ようこそ ゲスト さん