「jboss」を含む日記 RSS

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

2019-07-05

日立子会社SIer)を退職しました。

2019年6月を持ちまして、大学新卒入社後約7年勤務した会社退職しました。

良い機会なので記録に残したいと思います

スペック

地方国立大学工学部情報科卒。保有資格基本情報応用情報技術者

入社理由大手っぽかったため(何も考えてない)。

会社業務概要

日立製作所の子会社としてシステム開発運用保守、構築を担う会社

社員数は2~3000人。

入社してから運用、構築業務を行い、開発は未経験担当したシステムの分類は公共系のみ。

基本的には「客先常駐」で、システムが安定稼働に入った段階で別のプロジェクトに参画し、構築を行った。

身についたスキル

インフラ設計、構築

サーバ構築(オンプレミス業務としてOSMWの導入に携わることで、構築に必要知識を得られた。

ちょっと残念だったのが日立製品(JP1、uCosminexus Application Server)に携わる期間が長かったこと。

他社のAPサーバWeblogicJboss等)も触れ、インフラ屋さんとしての価値を高めたかった。

マネジメントスキル

力不足ではあったが5年目ごろから小さいチームのリーダになり、進捗管理顧客調整等を行った。

チームは3~5人でプロパー1人(私)、他は協力会社構成

協力会社メンバーは全員年上で、コミュニケーションにおいて苦労した部分もあったが、

人に恵まれ、大きな問題なくプロジェクト遂行できた。若いうちにリーダーを経験できたことはとても良かったと思う。

給与

最終年度で約560万。

◆内訳

 ・基本給 :26万

 ・扶養手当:2万(子ども二人)

 ・残業手当:8万(平均30時間/月)

 ・賞与  :約60万(年2回で業績により若干増減あり)

残業代は基本全額支給のため、それによって年収は大きく増減。

そのため、仕事がないのに残業するという所謂生活残業」をする人も少なからずいる。

また、最近働き方改革で定時退社を励行しているため、残業についてはかなり厳しくなっている。

昇給・昇格

昇給は若干ではあるが、たぶん毎年した。

昇格については、早い人で8年目から主任、15年目くらいで課長になる。

主任年収が600~800万(残業による)、課長年収が900~1000万。

主任まではある程度の実績とポイント資格等)があれば誰でもなれる(はず)。

ただ、課長以上になると「上が詰まっている」&「製作から下ってくる」ため、相当優秀でない限りはハードルが高いと思う。

劇的に仕事が増えて部&課が新しく作られれば話は別だが。

働き方

プロジェクトに合わせる形になるが、フレックスのため勤務体系が自由

上述の通り、残業についても働き方改革で定時退社を励行しており、男性の育休取得も推進している。

環境についてはシンクラ端末が一人一台支給され、インターネットがつながる場所であればどこでも仕事ができるという状態

どこでも仕事ができてしまうため、公私のバランスがとりずらいという方もいるかもしれないが、私にとっては最高でした。

これさえあれば在宅勤務も可能なので、娘が熱を出し保育園に行けないときは重宝した。

また、複数拠点サテライトオフィスがあり、社員証があれば使用できるため、打合せで移動が多い日はよく利用した。

働きやす環境作りにはかなり投資されているため、恵まれ環境仕事ができたと思う。

退職理由(順不同)

残業しないと給料低い。また、担当レベルだと成果を出した人とそうでない人で給与の差がほとんど付かない。

・新しい技術に関する感度が低い。

意識低い系がそこそこ多い。そしてその人たちは決して辞めない。優秀な若手はどんどん辞めていく。

SIerあるあるかもだが、協力会社に丸投げのプロジェクトがけっこうある。

・道半ばなのは重々承知なのだが飽きた。

SIer自体の将来性のなさ。

まとめ

転職先は事業会社IT企画部です。次が身の丈があった環境かどうか不安もありますが、新たな環境にワクワクしています

次の会社で働いてみて、前職の良し悪しもさらに見えてくると思うので、また気づきがあれば書きたいと思います

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メソッドフィルタリング)です。

2014-09-05

1人教祖

僕たちはいだって宗教戦争だ。

エディタで。vimキーバインドで。teraterm背景色で。ログファイル名称で。変数名で、タブの桁数で。spfileの設定で。jbossの設定のおまじないで。stratsの継承方法で。エラークラス名で。プロパティ名で。セッターゲッターを付けるかつけないかで。コンストラクタで。newを上書きするかしないかで。jreのeditionで。eclipseの見た目で。javadocのエディションで。クラウンドキュメントIDで。githubにいくつ持っているかで。tryのインデントで。タブを表示するかしないかで。エディット中の飲み物で。待ち合わせはスタバなのかエクセルシオールなのかで。セブンイレブンコーヒーサイズで。そのコンビニコーヒーが一番うまいかで。IDカードは伸びるストラップがいいのか悪いのか。寝るときは机の下か椅子を並べるのか。デスクの上にフィギュアは置いていいのか悪いのか。めんまつるこか。

いつだって宗教戦争の糸口が僕たちを待ち構えている。とても恐ろしいことだ。

2014-09-03

http://anond.hatelabo.jp/20140902163444

理由くらい書けよ糞が

Windowsだけでしか動かなくてもいいからスタンドアロンプログラムが作りたい → (簡単なことだけでいいなら)C#、(メモリ効率が求められるなら)C++

他のWindowsプログラムがやっていて、多くの方が「できて当然」だと思っていることは、7割くらいであれば.NET(フレームワーク名)を叩けばできます

.NET対応言語C#VB.NET、J#、F#JScript.NETC++/CLIなどがあり、実際の開発においてはこれらの中から自分に合った言語を選ぶことになります

個人的感想ですが、この中で最もゆとり仕様なのはC#です。StackOverflowなどのノウハウが一番蓄積されているのもC#だと思います

「頻繁なアップデートを追跡しないといけない」「Visual Studio必要」という問題はありますが、がんばってください

なお、.NETメモリを食うので、数値計算みたいなことをしたいのであればC++が現状一番まともだと思います。がんばってください

Macプログラムが作りたい → Objective-C

昔のMacプログラムGUICarbonというライブラリで作っていました。今はCocoaというライブラリで作っています

残念なことに、どちらも言語Objective-Cです。がんばってください

ブラウザアプリが作りたい → クライアントJavaScriptサーバは後述

ブラウザアプリは、ユーザWebブラウザ(ChromeFirefoxOperaSafariなど)上で動作するシステムと、遠隔のサーバ上で動作するシステム連携して成立します。

従って、ブラウザアプリを作る言語は、サーバ用言語とクライアント用言語の2種類を考えなければなりません。めんどくさいですね。

ひとたびそのめんどくささを突破してしまえば、Webブラウザさえあればどこでも動くようになります。素晴らしいですね。

クライアント用の言語は、まぁ、JavaScriptしかないと思います。がんばってください

JavaScriptも(正直なところ)あまり褒められた言語ではないので、近頃ではもうちょっとまともな言語を作って、それをJavaScriptに変換する方法が取られたりします。CoffeeScriptTypeScriptHaxeとかですかね。がんばってください

JScriptかいう、名前が紛らわしい上にゴミブラウザ上でしか動かないゴミ未満言語もありますけど、そんなもんで作っても私の環境では動かせませんので悪く思わないでください。

iOSネイティブアプリが作りたい → Objective-CSwift

そもそも選択肢が全くありませんので仕方がないです。がんばってください

Xamarinがあるじゃないかって?まぁそういうのもあるかもしれませんね。がんばってください

Androidネイティブアプリが作りたい → Java

私の勉強不足で、Java以外の選択肢は知らないです。Java以外にあるんですかね?

*NIX用の補助スクリプトを作りたい → PerlPython2、Ruby

Perl使い捨てスクリプトを作るのに適していますCPANクライアントは昔から安定して動きません。だいぶオワコン化してます。がんばってください 私は鞍替えしました

PythonPerlより見た目がすっきりしたPerlです。easy_install・pipはすごく安定していてびっくりします(Windows除く)。3系とかいう邪念は捨てて2系教の悟りを開きましょう。がんばってください

RubyPerl(の処理系ソースコード)より(処理系ソースコードが)綺麗なPerlです。私の手元のUbuntuで「ruby」と入力すると「Command not found.」と返ってくることからも解るとおり、多くの*NIXではOS標準でインストールされておりません。昔のgemは何故あんなにすごい時間をかけてrdocを作っていたのでしょうか。日本人が作ったのでムラ意識の強い日本人の仲間が大勢ます。他の国は知りません。がんばってください

*NIX系のOSでミドルウエア的なものを作りたい → なんだそれ?何を作りたいの?

ゲームを作りたい → どんなゲームだよ…

言語処理系を作りたい → BNF、C

これ以上言語を増やすのはやめましょう。バベルの塔大勢人間が不幸になったのに、それを人間が自ら引き起こしてどうするんですか。

言語処理系を作るのであれば、BNFという言語で文法を定義して、yacc・bisonというツールに食わせればひな形ができます。ぶら下がりelseとの格闘が待ってますが、がんばってください

OSを作りたい → C

1からOSを作った方もいますが、デバイスドライバの流用などを考えると、だいたいはLinuxBSDソースコードを改変するお仕事だと思います

残念なことにLinuxBSDもCです。がんばってください

ブラウザアプリ用のサーバが作りたい → PHPJavaC#Go

昔はCGIと言っていました。所詮は80番ポートでlistenするだけのプログラムであり、BSDソケットをlistenできるライブラリを有する言語であれば何でもいいのですが、いくつかの宗教があります

PHPバンドネオンと同じくらい習得が困難な言語なのに、宣伝の仕方を間違えたために「自分はできる」と勘違いしたプログラマが暴徒と化し、イスラム教と同じくらい不当に低く評価されている言語です。きちんと勉強して使う分には、悪くない選択肢だと思います。がんばってください

Javaは、EclipseNetbeansといった超重量級IDEを起動して、Java EESpringといった超重量級ライブラリ依存したwarを、JbossWebSphereなどの超重量級アプリケーションサーバ上で動作させるため、メモリが貧弱な環境ではIDEサーバを同時に起動すらできません。サーバメモリが潤沢であれば悪くない選択肢だと思います。がんばってください

C#は、選択肢が全くないことを除けば、状況はJavaとあまり変わりません。Microsoftがお好きな方、何かの間違いでWindowsサーバを使わざるを得ない方であれば、悪くない選択肢だと思います。がんばってください

Goはよくわからないですがきっといい言語です。がんばってください

ちなみに増田はcpoll_cppspの勉強中です。がんばります

2012-05-18

ハッカーVimを使う」 騙される若者たちなのか

Eclipseemacsvimより優れている点を挙げてみよう。

 

 

リファクタリング機能が強力 →本当か

CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか

デバッガグラフィカル → それ、うれしいか

・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか

復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし

 CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの

 ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能存在する。

プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない

プラグイン開発環境Eclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね

ライセンス形態CPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの?

・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸?

IBMバックアップがついている。→それは何か役に立つの

Smalltalkで有名なVisualworksの影響を受けているため、

JUnitプラグイン(Eclipse標準装備)によるテストファーストリファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね

SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力!→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ

・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ!→スタック見るだけのことじゃないの

プラグインによってはURLを指定するだけでプラグイン自動ダウンロード自動インストール

自動アップデートができるためプラグインインストールが非常に容易。→勝手に変わったら怖くない

Eclipseから直接Tomcat, JBossなどを再起動できるSysdeoプラグインJBoss-IDEプラグイン

 という強力なプラグインが充実している。→えー、今頃Tomcat

EclipseUML Omondoプラグインによりクラス図などを書いたり、

 UMLによるModel Driven Architecture, リバースエンジニアリング

 などを即座に実現できる。→これは何だかからない

RSSリーダープラグインMP3プラグインAll The Newsプラグイン

など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね

PHP開発が可能なTruStudioプラグインPerl開発が可能なPerl E.P.I.C. プラグイン

C/C++開発が可能なCDTプラグインAspectJ開発が可能なAJDTプラグインなど

言語プラグインが充実している。→Java以外は所詮おまけだけどね

・そのほかにD言語プラグインC#プラグインPythonプラグインJavaScriptEditorプラグイン

CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン

Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン

ゲームができるプラグイン、メーラとしてつかえるプラグインWikiプラグインHibernateプラグイン

FindBugsプラグインCheckStyleプラグイン、JalopyプラグインSobalipseプラグインソロプログラマープラグイン

など様々なプラグインが充実している。→それぞれ単機能ソフトのほうが充実してるんじゃないの

 

 

どうしてもeclipseというなら止めないけど

2012-02-17

ハッカーVimを使う」 騙される若者たち

Eclipseemacsvimより優れている点を挙げてみよう。

 

 

リファクタリング機能が強力

CVSリポジトリの構成を直接覗ける

デバッガグラフィカル

・設定できる警告メッセージの種類が豊富

復元機能が非常に充実している。

 CVSのように以前の状態に復元すること、以前の状態の

 ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能存在する。

プラグインの数が豊富、膨大。

プラグイン開発環境Eclipse自体に用意されている。

ライセンス形態CPLであり商用利用もしやすい。

・上位版にWSADが存在する。

IBMバックアップがついている。

Smalltalkで有名なVisualworksの影響を受けているため、

JUnitプラグイン(Eclipse標準装備)によるテストファーストリファクタリングの他、eXtreme Programming環境が充実している。

SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力!

・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ!

プラグインによってはURLを指定するだけでプラグイン自動ダウンロード自動インストール

自動アップデートができるためプラグインインストールが非常に容易。

Eclipseから直接Tomcat, JBossなどを再起動できるSysdeoプラグインJBoss-IDEプラグイン

 という強力なプラグインが充実している。

EclipseUML Omondoプラグインによりクラス図などを書いたり、

 UMLによるModel Driven Architecture, リバースエンジニアリング

 などを即座に実現できる。

RSSリーダープラグインMP3プラグインAll The Newsプラグイン

など様々なプラグインが充実している。

PHP開発が可能なTruStudioプラグインPerl開発が可能なPerl E.P.I.C. プラグイン

C/C++開発が可能なCDTプラグインAspectJ開発が可能なAJDTプラグインなど

言語プラグインが充実している。

・そのほかにD言語プラグインC#プラグインPythonプラグイン、JavaScriptEditorプラグイン

CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン

Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン

ゲームができるプラグイン、メーラとしてつかえるプラグインWikiプラグインHibernateプラグイン

FindBugsプラグインCheckStyleプラグイン、JalopyプラグインSobalipseプラグインソロプログラマープラグイン

など様々なプラグインが充実している。

 

 

以上、老害に騙されずにEclipseを使いましょう。

2008-12-18

いっそ英語の方がわかりやすい。

jboss2.4.3で、entitybeanに対してremoveメソッドを呼んだ場合、 <<

なぜかbeanのキャッシュobjectが残存していて、さいど同じprimarykeyで

create後removeすると、remove内でDBへのconnectionを解放している

場合にSQLExceptionが発生する。やはりjbossエラーだそうな。

一番最初のremoveでconnection.close()を呼んだままになってるから

当然。SunEJB仕様によれば、ejbRemoveとejbPassivateはともに

beanをプール状態に移行するもので(つまり同じ動作)かつejbRemoveでは

ストレージに登録された実データ削除することになっている(SQLのDELETE文やね)。


日本語じゃねえ。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん