「Struts」を含む日記 RSS

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

2019-06-29

azure概要勉強してるんだが、どうもこれ、意識高い系新しいもの好き自称クリエイター保守性も考えず好き放題作り散らかす未来しか見えないな

strutsspringのように今や負債しかないフレームワークと同じようなゴミになりそう

2019-06-21

Javaをメインで書いているわけではないけど

別にJava良くないか

なんならRubyより静的言語だという点で優れているような。

最近Go流行っているが、それならJavaだって同様に良さそうな気がする。

Java批判すべき点ってなんなんだろう。

- 記述冗長

- nullがたまにうざい

- なんか重厚な感じがする

- 重厚アーキテクチャ流行りすぎた?

- ORMとかが重厚なのが多かった

- ビルドツールが洗練されていない時代があった

- 故に環境構築が大変だった

- tomcat + jar みたいなのがだるかった?

- strutsがしんどかった

- 未だにstruts脆弱性が見つかったりするところ

- xml地獄からアノテーション化したりいろいろと模索していた

- なんかJava案件地雷が多かったとか?

- ちょっと昔には「俺たちイケてるプログラマ」はみんなRailsに移っていった流れがあった?

- Effective Javaよいが、そもそもそういうtips意識せずにそう書けるような言語仕様になってほしかった気もする

- 非同期処理やスレッド処理がやや難しかたか、あるいは言語側でのサポートが薄かったか(?)

言語仕様的な批判と、エコシステム的な批判に分けられそうなきがするな。

関数型言語の関心はScalaClojureに全フリしてもらって、Javaシンプル機能を持つGo方向性なModan Javaになっていってくれれば良さそうな気も。

httpサーブレットとかそのへんが微妙だったかもしかしてGoみたいにnet/httpライブラリが標準であればそれをベースにすることでオレオレフレームワークの乱立を避けることができるか、と思ったけどJAX-RSとかがあるな。

Goだって冗長記述必要言語だが、好かれているし、Javaも悪くない言語な気がするんだよな。

まあ何でもいいが。

ロジカルに考えているようで結局なところ雰囲気的なところに左右されているエンジニア多い気がする。

まあわいも、人気な言語に乗っておいて高単価を得られたほうがいいのでそうするが。今の所Goが肌にあっているんだよな・・。3年ぐらい使って熟練度上がってきたし、さほど悩まずにコーディングすることができる。

PHPの人が好きな、あるいはRubyのmethod_missingなど活かしたテクコードは、書いているやつは気持ちいかもしれないがわいは明示的にinterfaceがわかるコードが書かれていたほうが好きだ。型で振る舞いがわかったり制御されていないと分かりづらくない?複数プロジェクトを掛け持ちするから、読むときに前提知識が少なく読めるコードがいい。

まあJavaもリフレクションでテクいことができる気がするな。

Goがいい。誰が書いてもだいたい同じコードになるから、誰かに作業を振ったとしてもレビューやすい。

まあこれからJavaを書く気はしないが、GoAPI書いているマンから見ると、JAX-RSとかでゴリゴリAPI書いていくの全然悪くないんじゃないかと思うのであった。

最悪別にGeneric入らなくてもいいかもな。別にそんなに困ってない。はいってくれるなら、はいってくれたほうがいいが。sliceに対してmap, each, filter, existsなどのメソッドが生えることになるイメージかな。まあそれは欲しくなるけどな・・・

Scalaもいいんだが、たまにイキったコードを書くと分かりづらくなる時がある。イケてるコードを書こうと思ったとき結構パワーを使う言語だ。なんかモナドってジェネリックを更に強くしたやつだとも捉えられるような気がするな。ゴリゴリ関数型で書こうと思った場合プロジェクト全体に影響がある話なのでアーキテクチャ設計に力がいる気がする。

年をとると大事にするポイントが変わってくるな。昔はスーパープログラマになりたくて関数型言語とかやっていたが、今はいかに効率よく仕事をする=金を稼ぎ自由を得るかを重視している。職業プログラマとなったわけだ。仕様固めたりリリースしたり不具合対応したり運用したり、フリーランスなら税金計算したり、金儲けの方法考えたり忙しいんじゃ。今は結局スーパープログラマとは何か悩ましいよ。「プログラマとして」キチガイレベルにすごい人間というのはまだ見たことがないかもしれない。コーディングが早い?バグ修正が早い?パフォーマンスやばいコードを書ける?設計が優れている?

わいのレベルが低くて、高い人間凄さに気づけていないのかもしれないな。

2016-10-22

15年ものStrutsの社内向けシステムの維持開発にここ2ヶ月ほど携わっていたのだが、ソースが残念すぎた

明らかに低レベルなんだ

自分は言っても業務屋で、あるものを見て真似て短期間でものを作ることを良しとする程度の技術レベル

そんな自分が見ても明らかにイケてない

当時の新人さん達をかき集めて作り、そこからまり進化もしなかったという感じのシステムだった

そんなシステム機能を追加する案件

元になる処理はどこかしらに似たものはある

けどその処理を探した後も、そのまま利用はできない

解読するのにまず時間がかかり、イケてなさに我慢できず結局自分で書き直す

結局時間はかかってしま

なんだかなあ、と思う

2016-01-23

SIはやめておけ

20代の数年間SIで働いた。1年以上前退職して今は別業界にいる。

今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくり暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。

一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。

以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。

工数至上主義

受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積おかしくても顧客と対等な関係が築けていないから追加請求もできない。時間(工数)をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。

まり、どう頑張っても売上は同じなのだから、良いもの価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。

これが諸問題の根源で、いかに述べるような組織プロジェクトが出来上がっていく。

作業効率化しない

マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。

私は定型作業効率化しようとjsやrubyスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。

あるとき上司に肩越しに自分作業を覗かれて「何やってるの?」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの?工数に乗ってないよね?」「スクリプトテストもちゃんとしないと結果が正しいって保証できなくない?」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分作業工数内で完結する。むしろ工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず(読めないので)1時間無駄にした。

技術力いらない

前述したようなビジネスモデルから営業力と、予定工数で無難プロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者人材派遣系の企業や下請けにいっぱいいるから。

社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術=技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。

そういう人が集まっているor残っている組織なので開発者ほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム部長お気に入り課長になり、部門長のお気に入り部長になる。その繰り返し。

開発案件でのBP(ビジネスパートナー委託先、派遣下請け比率自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い=マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。

私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。

意識の低い開発者メンバー

上述の通り、案件で接する開発者基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。

まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度(この場合顧客は私が所属する企業)、請負場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズド世界で生きている。

そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルール説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステム課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループ疲弊の一因だ。

static BP

ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパー技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。

だが、拍子抜けした。あまりにも仕事が雑なのだコミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分ブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。

また、彼はJavaの有名なフレームワークであるStruts拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークバージョンを上げると壊れるというのが残念な点で負債になりかけていた。

私は異動したが、彼は今でもそこにいると聞いた。

技術の話

テストコード書けない

(最低限のものしか作らないから)安くて早い!という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何?」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの?』って問われるから絶対言うなよ」と拒否された。

保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。

リファクタできない

先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコード顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。

レビューない

私がいたどの案件にもコードレビューがなかった。リーダー開発者数人という構成場合、まず開発者は全員下請けリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステム挙動実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解齟齬が頻発していた。特に入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。

そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。

新規技術試せない

無難プロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業マネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術(言語フレームワーク)がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらラッキーぐらいの考えでいる。

常に横に倣えのアーキテクチャは私にとって面白くはなかった。

横に倣え

また横に倣えが加速してさらに悪い事に、同じアーキテクチャネットワーク再利用するために既存のサーバに新システム相乗りすればよいという発想も珍しくない。「資産再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックオンプレミスサーバ上で複数アプリケーションサーバ運用した結果、予想通り耐障害性が下がった。

また、Oracleライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システム共倒れになったこともあったがOracleのバグとして報告していた。

static Perlおじさん

新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。

まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか?」と聞いたら「Perlクラスなんて必要ない。構造プログラミング研修でならってないのか」と返ってきた。「俺が前に書いたPerlバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。

また、そのプロジェクトのメイン言語Javaで、Eclipseを使っていたのでPerlプラグインを入れてコーディングデバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグイン品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタしろと言っただろ!」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。

待遇・制度

給与

SI業界の中では高いのかもしれないが決してよくはない。4年目(たぶん25歳)ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。

個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。

マシン

会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者基本的デスクトップ使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。

組織問題

とにかくクローズド組織

つの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから

情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメール添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダ権限を持った人間しか見られない。何で他の部や課が行った過去の見積提案資料自由に見られないんだよ。

ソースコードリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。

会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。

意思決定の遅さ

どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクト利害関係者ならまだわかるものの、まったく関わっていない上長(課長部長、時には部門長)を通さないと進まないという異常さ。

コスト削減

利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自ノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員デスクトップを使っている。ITとは。

本当に無駄しか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員派遣で雇うべきという提案が何度もされたが、課の予算オーバーするから無理だという回答しか返ってこない。

残業削減

表向きは社員健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システム監視し、削減できていない組織や人間評価を下げるようになった。

その結果、サービス残業が復活した。30時間を超えると部長説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員残業時間を管理するとかい無駄な仕事を増やしたし、管理される社員ストレスサービス残業に繋がったので下策だと思う。

他人残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。

そもそも無駄作業や工数至上主義作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。

辞め方

2014-05-13

派遣会社経由で内定を貰ったが辞退した

今回派遣会社経由でとあるIT系会社(以下D社)の内定が決まったが、その内定を蹴って良かったと思う話をしたい。蹴った決め手は、会社側が実務でJavaを触った事ありますと経歴書を偽造したこと等もあり、会社に対する不信感が募ったからだ。

まずA社の方から内定をもらう。しかしどういうわけか労働契約書の話も無く、系列(?)のB社に送り込まれる。A社とB社の面接の際、俺の単金の話が出て来たあたりまずいなと察知。この時点でA社は俺を送り込んで、お金を取りたいだけという感じだ。この段階で辞めますと言えば良かったのだが、ずるずる続けてしまったのが落ち度だ。

そしてB社の方で派遣先(C社やD社)の面接練習をした訳だが、 要件定義テストなどやった事がないものをあると答えろと言う指示も多く非常に困った。Javaと言っても、ままごと程度にしかできないしかstrutsと言ったサーバーサイドのフレームワーク経験もなく、面接が決まってから仕様の確認をする始末。

その一方面接で「Javaで何が出来ますか?」と聞かれても、「strutsフォームを作る練習中です」位にしか答えられず敗北。そんなこんなで「Javaお金を取って来て欲しい」と言う話もあったものの、Java関連の案件は全て失敗。結局PHPの方の案件が通った。その時並行で数社受けていたが、落ちた会社や他に受かった会社の説明が無い点があって、余計不信感が募っていく。

そして何故他社を見下す発言が多いんだろうね?とずっと疑問に思っていて、直感的に止めた方が良いと思い内定辞退。その際言い合いになり、C社やD社の案件が惜しい気持ちもあったが、結果的に辞めて良かったと思う。

皆さんもこういう人を舐めた会社には、くれぐれも気をつけてほしい。

2014-04-03

社会的技術負債をなくすには

社会的技術負債をなくすには

動的言語は使わない。

動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)

動的DBは使わない。リレーションのない動的DBは使わない(mongoDBNoSQL系)

動的オープンを紹介してくるメデイアのステマ気づき騙されない

動的オープン無料育成研修セミナーには行かない

Silerが勧めてくる技術独立できない技術からやらない 関わらない

職務経歴書黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない

マニアックオープンソースは拾ってこない 広めない

Jser Phper Rubistにならない 奢らない

PHP Java JavaScript Ruby RoR Html5仕事は請け負わない

技術負債をなくすには

C# Objctive-cだけ使う

VisualStudio Xcodeだけ使う

VisualStudio Xcode機能をフル活用する

WindowsServerを使う

一定シェアを獲得したDBを使う

デザパタを覚える

コミュニケーションOffice 365 redMine,イラレGit Svnを使う

動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな

セキュリティに問題のある動的言語はどこにいってもトラブルになる

原発システムRuby,RoR,PHP,JavaScriptを使いたいと思うか?Silerはなら提案してくるだろう儲かるから

使えば必ず原発はハックされる

C# ASP.net2007年から海外では大流行だった 一方日本メディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた

C#(静的言語)は14年前のソースが今でも使うことができる。VisualStudioにはソース自動バージョンアップ機能があり書き換えてくれる。 コード負債にならない コンパイルバグがわかる DLLバージョンをチェックしてくれる ブレイクポイント リモートデバッグ

動的言語オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ機能追加のたびに修正することになる リファクタが使えない 負債言語

>14年前のソースが今でも使うことができる

この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか?関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性仕様変更がたくさん埋まっているソースだ 修正には手間と時間予算がかかる

C#なら一瞬で最新の.netフレームワークバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単

PHPを捨てたほういい理由

http://apps.wiki.fc2.com/wiki/PHP%E3%82%92%E6%8D%A8%E3%81%A6%E3%81%9F%E3%81%BB%E3%81%86%E3%81%84%E3%81%84%E7%90%86%E7%94%B1

今はRoRステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更バグ脆弱性は出続け、そのたびに全ソース検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要中間業者は儲かるのでメディア無料育成を通して広めてくる 煽っておいて自己責任の国 日本

静的言語サーバーサイドで何がいいかというと 自分は C# Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方

もうお分かりいただけただろうか?動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語いつまでも高い稼働の保守作業が必要だ。機能追加、言語仕様変更脆弱性修正するのにお金時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。

これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語マスターたからといって独立はできない。なぜなら、5人以上のプログラマーが働いてやっと出来上がるものほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。まさにIT版のねずみ講  上のしか儲からないようになっている。 それに加えて酷いピンハネ。100万で売って7割以上搾取 一人送れば70万円入る世界だ。Silerにとって開発現場炎上すればするだけよい。言語脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人適当教育して3年開発の下駄はかせて送り、現場炎上させて新たに人を送り込んで利益を得ている。

メモ

#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報流出すること結構あるようだ @WikiPHP

#2 2013年 Javaフレームワーク Strutsサポートが終了した こういうフレームワークをメデイアで煽っておいて最後自己責任される。オープン言語はやってはいけない

#3 これはどの業界にも言える事だが、気合い、根性気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーション社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。(○ーイズ、○ルマー、○ニー、旧日本軍ジオン軍タバコ室や残業特定社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる

#5 仕事の最終目的コミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。Office 365RedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ

#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る

#9思えばSiler業界自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率生産性保守作業は社会進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的スキルしか身に付かなかった。それしかやらせてもらえなかった。

しょーもない言語社会の発展を止め、技術者を路頭に迷せた。有益言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたのではないか?

C#ロボット組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。

特にロボットはMocrosoft Robotics StudioというVisualStudioロボット版の開発環境2006年から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界JavaLampが主)

続き

http://apps.wiki.fc2.com/

2014-03-14

社会的技術負債をなくすには

技術負債をなくすには

C# Objctive-cだけ使う

VisualStudio Xcodeだけ使う

VisualStudio Xcode機能をフル活用する

WindowsServerを使う

一定シェアを獲得したDBを使う

デザパタを覚える

コミュニケーションredMine,イラレGit Svnを使う

社会的技術負債をなくすには

動的言語は使わない。

動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)

動的DBは使わない。リレーションのない動的DBは使わない(mongoDBNoSQL系)

動的オープンを紹介してくるメデイアのステマ気づき騙されない

動的オープン無料育成研修セミナーには行かない

Silerが勧めてくる技術独立できない技術からやらない 関わらない

職務経歴書黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない

マニアックオープンソースは拾ってこない 広めない

Jser Phper Rubistにならない 奢らない

PHP Java JavaScript Ruby RoR Html5仕事は請け負わない

動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな

セキュリティに問題のある動的言語はどこにいってもトラブルになる

原発システムRuby,PHP,JavaScriptを使いたいと思うか?Silerはなら提案してくるだろう儲かるから

使えば必ず原発はハックされる

C# ASP.net2007年から海外では大流行だった 一方日本メディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた

C#(静的言語)は14年前のソースが今でも使うことができる。VisualStudioにはソース自動バージョンアップ機能があり書き換えてくれる。 コード負債にならない コンパイルバグがわかる DLLバージョンをチェックしてくれる ブレイクポイント リモートデバッグ

動的言語オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ機能追加のたびに修正することになる リファクタが使えない 負債言語

>14年前のソースが今でも使うことができる

この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか?関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性仕様変更がたくさん埋まっているソースだ 修正には手間と時間予算がかかる

C#なら一瞬で最新の.netフレームワークバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単

&blanklink(PHPを捨てたほういい理由){http://www.slideshare.net/neuecc/c-22979400?v=qf2&b=&from_search=42}

今はRoRステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更バグ脆弱性は出続け、そのたびに全ソース検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要中間業者は儲かるのでメディア無料育成を通して広めてくる 煽っておいて自己責任の国 日本

静的言語サーバーサイドで何がいいかというと 自分は C# Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方

もうお分かりいただけただろうか?動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語いつまでも高い稼働の保守作業が必要だ。機能追加、言語仕様変更脆弱性修正するのにお金時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。

これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語マスターたからといって独立はできない。なぜなら、5人以上のプログラマーが働いてやっと出来上がるものほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。それに加えて酷いピンハネ。100万で売って7割以上搾取 一人送れば70万円入る世界だ。まさにIT版のねずみ講  上のしか儲からないようになっている。Silerにとって開発現場炎上すればするだけよい。言語脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人適当教育して3年開発の下駄はかせて送り、現場炎上させて新たに人を送り込んで利益を得ている。

メモ

#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報流出すること結構あるようだ @WikiPHP

#2 2013年 Javaフレームワーク Strutsサポートが終了した こういうフレームワークをメデイアで煽っておいて最後自己責任される。オープン言語はやってはいけない

#3 これはどの業界にも言える事だが、気合い、根性気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーション社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。(○ーイズ、○ルマー、○ニー、旧日本軍タバコ室や残業特定社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる

#5 仕事の最終目的コミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。 RedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ

#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る

#7思えばSiler業界自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率生産性保守作業をしている間に社会進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的スキルしか身に付かなかったしそれしかやらせてもらえなかった。

しょーもない言語技術者に学ばせて社会の発展を止め、技術者を路頭に迷よわすよりも、有益言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたはずだ

C#ロボット組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。

特にロボットはMocrosoft Robotics StudioというVisualStudioロボット版の開発環境2006年から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界JavaLampが主)

Amazon倉庫ロボット自動システム

http://gigazine.net/news/20121231-kiva-system/

それを開発している会社採用情報 採用言語C++ C# Java

http://www.kivasystems.com/careers-at-kiva/

PHP RoR JS Rubyなんてどこにも書いていない 数年もすれば仕様が変りバグ脆弱性を出す危ない言語だとわかっているのだろう こんな危ない言語は使ってはいけない

Mocrosoft Robotics Studio

http://www.saturn.dti.ne.jp/npaka/robotics/index.html

https://www.microsoft.com/en-us/download/details.aspx?id=29081

続きはWEB

http://goo.gl/2nwGh

2013-09-26

HTML5アプリケーションとかでも良いから誰か名称つけようよ

下見て思った。

http://mizchi.hatenablog.com/entry/2013/09/25/190313

そもそもこのスタイルキー名称が無いため

知識が離散して蓄積されてない気がする。

シングルページスタイルJavaScriptWebアプリケーションアーキテクチャ

ブラウザHTMLで動くよ!

JavaScriptMVCライブラリを利用するよ!

HTML5ヒストリー関連を利用するよ!

REST-APIを利用するよ!

メリットとかデメリットとかはいつか気が向いたら書く。

とりあえず今回は、乱立する名称候補たちを紹介

HTML5 Applications

 なんか一番ポピュラー。だけどカオス

 HTML5って言いたいだけのJavaScrtipt使ったスマホアプリフレームワークとかも呼ばれたり。

Rich Internet Applications

 このスタイル名称じゃなく、もっと汎用的なもん。

 HTML5とか言われる前にJavaScriptアプリケーションやるとこれになってた。

 GWTとかExtJS,YUIとか懐かしい。

Single Page Application

 アーキテクチャとしては、もっとも正解の名前なのだが、NET系界隈でしかきかん。

 ASP.NET MVC Single Page Applicationは、キー要素がかなり詰まってて、参考になる。

 このあたりのやろうとしてる奴は一度触っておくが吉

Large-scale JavaScript aplication

 JavaScriptMVCライブラリAMD等の依存モジュール管理とか

 最近流行を組み合わせて巨大なアプリを作る指針。

 英語ソースだと結構ポピュラーな感じの名前だが、指針的な匂いアプリケーションとは言わない感も。

 日本でも一時期、大規模Javascript開発とか言われてたが、Bakcbone.jsって名前に変わった。

JavaScript Web Applications

 Node.jsと被るために、このアーキテクチャの説明にはあんまり使われない。

 動物本の、

 「ステートフルJavaScript MVCアーキテクチャに基づくWebアプリケーションの状態管理

 原題は、「JavaScript Web Applications」

 これだけで、どのぐらい困ったか分かる感じ。

 ちなみに、JavascriptMVCアーキテクチャの解説本としてはありなので読むが吉

ダイナミックHTML

 マイクロソフト原理主義

 といっても、10年ぐらい前からXHRHTMLDOMほげるのは

 実はあんまり変わってない。

Thin Server Architecture

 Java界隈から出したかっただけ。oracleが呼んでた気がする。

 Struts死んだけど、JSFでやるの?JSF無理筋だから違うフレームワーク作るの。

 JSFみたいな抽象化使い始めると、コボルみたいにJava世界に閉じそうだけど大丈夫なの?

JavaScriptMVC

 同名のライブラリがあるせいであまり使われない名称

 このあたりのライブラリ使えば、簡単にこのスタイルアプリ作れると思ってるでしょ?

 残念ー、あくまでもMVC構造しか提供しないんすよー

Backbone.js

 上記の、キー検索ワード

 ライブラリ名称なのだが、背負ってるものは、大体この界隈全て

 だけど、使えば、この界隈のアプリが簡単に作れるかというと、そうでもない。

と、まあ名前はいっぱいあるけど、知られてないという感じもする

2013-09-01

BtoBとBtoCの技術が逆転する時代

アーキテクチャWebオンリー偏見満載で語ってるみる。

ここ10年のBtoBの成果は、共通の技術基盤という妄想のために用意された

複雑大規模で、完全に閉じてて、他には誰も使えないEclipseで動く謎のゴミ

JavaっぽいJavaっぽいJavaっぽい何かで

自分達でも持て余して、パッケージ導入とか、結局Strutsスクラッチ開発だったね。

まあ、商売ネタとしては成立してたけど。

Struts1のサポートが切れる蓋を開けた時の状況は、笑いどころか失笑でした。

からってBtoCも凄かったわけじゃない。

やすいはやいゴミを量産する方向にシフトした。

PHPとかPHPとかPHPとかで

そこで事件が起きる。Railsの登場。

ビジネス的には、あんまりインパクトはなかったこれだが、歴史の転換を説明するのには便利。

Railsアーキテクチャは、エンタープライズアーキテクチャパターンを程よい感じに取りこんでいる。

馬鹿にでも使えるようにしたもので、これが世に放たれた。

そこからBtoCのアーキテクチャの質が一気に上がる。

さんざんdisられるPHPの良さは、その哲学の無さだ。

Perlパクりから始まって、Javaクラスパクッて、Railsも速攻パクった。

最近は、所謂関数言語と分類されるパラダイムも最速でパクてる。

そんな感じで、RailsからパクッたフルスタックMVCフレームワークが一気に広まる。

そしてこれらのフレームワークは、金魚のフンSierにとって銀の銃弾だったStrutsを、

鼻で笑えるもので、Strutsドヤ顔してた彼らは、この時点からPHPerからも見下される存在になった。

ORマッパーを知らないおっさん。お元気?

エース開発リーダーさん。そろそろDIコンテナあたりは使えるようになった?

Javaの方が良いとか言うなら、せめてそのぐらいはフォローしたら良いんじゃないですかね。。。

さらには、大手BtoCのアーキテクチャ公開も普通になる。

アーキテクチャは、もはや商売道具じゃなくなった。

長年の秘伝の味を売りにしてたBtoBアーキテクチャは、

その汚い樽が馬鹿にされる時代突入する。

ただ、これは結果から見たもので、本来の本当の流れは、ネットの普及にある。

BtoCの市場が巨大化し、パイが増えて、それだけ技術者も集まった。

人が多ければ、優秀な人材が集まる確率も増える。

優秀な人材プロダクトを作れば、優秀なプロダクトが生まれる確率もあがる。

から進歩も速くなる。

みんなで作れば凄いものが作れるという勘違いは、決してしないように。

これはアーキテクチャにも影響して、その方向性を決めるようになった。

SOAPRESTなんかがまさに象徴

SOAPは、優れていなかったわけじゃない。ただ単に閉じた世界すぎた。

RESTは、実用的なアーキテクチャなんてほとんど無い。ただみんなが適当にやってたのに名前付けただけだ。

だいたい今はそんな感じで

今後はアーキテクチャはBtoCが主導するだろう。



ただし、これはアーキテクチャの話で、品質はまた別ですよ。

そこの社内SEさん。技術キーワードが凄いからって発注しちゃだめよ。

まともなもんが返ってくると期待しちゃいけない。

BtoBは、この鈍行の間、何もしなかったわけじゃない。

たった数パーセント稼働率を上げるために、何十倍時間や金をかけてきた。

実際、そういうものから仕方が無い。

彼らは、そういった品質に命をかけてきた。

設計書の文字のタイポレビューすると、単価計算で1万円以上は余裕でする。

大手Sier役割は、いつまでも必要だろう。

でも、その住人は、そういうものに命を捧ぐ時代である覚悟しないといけない。

2013-08-02

インターフェースとかちゃんと設計すれば必要ない。複雑にするだけ。

上司言葉

インターフェースとかそんなものをちゃんと設計を考えれば必要ない。複雑にするだけ。

リファクタリング必要を説明したところ…)バグでもないのに動いているシステムソースを書き換える?ふざけるな

Javaジェネリクスを見て)なんだこれは、ちょっとからいから説明して……ふむふむ、わかりにくいか配列しろ

DB正規化DBの使っていないテーブルの洗い出しという意味で使用)

UMLクラス図(フローチャートのこと)

Javaの最新は6(2013年言葉

JavaScript?あんな簡易言語なんて使えるのか?

(昨今のStruts脆弱性ニュースを聞き)よし!攻撃をされていないかチェックだ!ここのページ(なんかのニュース)を参考にして調査報告をしてくれ(Strutsは使っておりません)

役員言葉

昔ながらの静的でApacheのみで動く会社サイトについて)なんか簡単でいいからさ。資料問い合わせフォームみたいなのを作ってさ、メールが営業に飛ぶようにしてさ、そして問い合わせした会社データをためておい統計みたいなのをだしたいんだけど。

ほんと簡単なものでいいからさ。デザインとかは気にしないからさ。簡単なエクセルみたいなので出せるくらいでいいからさ。一週間くらいでできるかな

2011-12-07

http://anond.hatelabo.jp/20111207191239

これは規模じゃなくて難易度の話だろ

難易度の話をするならCで言うポインタの理解なりの例えがあるんじゃないか

javaだとなんだ、、、オブジェクト指向コード書けることか?

元増田に話しとくとjavaで開発するにもHadoopstrutsやらのフレームワーク

jspなどなど色々ある

Androidアプリはその中じゃそんなに難しい部類ではないと思う

別の言語使ってもAPIやらフレームワークやらOSやら言語以外の知識と理解は山ほど必要だ

別の稼ぎ口があってプログラマが向いていないと思うなら、今なら遅くないか

引き返したほうがいいな

自分は他に稼ぎ口がないからコレで生きていくしか無い

似たように苦しむ事が多いが腹をくくってる

2010-09-07

IT系とかそれ以外のスキル列挙するから何ができそうか教えて欲しい

色々教えてください偉い人。

自分で考えろってのはご尤もですが、色々な方の意見が聞いてみたいのです。

純粋Java(max5000行程度)

Struts(ver2じゃないほう)上でのJava(max2000行程度)

perl(max7000行程度)

c/c++(ちょっと)

Haskell(ほんの少し)

VisualBasic.NETじゃないほう)(ほとんど忘れた)

HTML/CSS(セマンティック厨)(HTML5勉強中)(バイトWEBデザイン経験有)

javascript(簡単なものなら)

XML/XSL自作プログラムI/Oに利用)

MovableTypeCMSとして利用。ちょっとした企業サイトレベルくらいのものの構築。簡単なプラグイン作成とかも)

Apache(セットアップと最低限の設定くらい)

Tomcat(同上)

LinuxCentOSUbuntu。セットアップとちょっとした設定程度)

IPA資格ソフトウェアネットワークデータベース

Tex論文プレゼンテーション作成

AdobeDTP製品(CS2)(雑誌編集経験有、ただし学生レベル

Oracle10g)(Bronzeレベルの知識とちょっと触ったことがある程度の経験

postgreSQL(ちょっと触ったことがある程度)

会計関連の知識(日商簿記2級)(大学管理会計をかじった)

数学系の知識(論理とか集合やらの基礎。大学計算機科学をかじった)

印刷物/WEBサイトデザイン(独学だけどそれなりに。一般人よりはそれっぽいデザインが作れるかと)

・文章/記事作成(取材→記事執筆。文章校正経験有)(随筆みたいのは無理)

漫画ゲームが大好き

2010-06-17

http://anond.hatelabo.jp/20100617181842

受託開発は固いけど確かに虚しい。

はてなだって最初は受託やりながらだったらしいし、

自分がやりたい事やるにも金かかるからなぁ

フレームワークの乱立は初期コストの増大をかなり招いてる。

特にHttpServletRequest世代とStruts+Spring+ibatis(hibernate)辺りだともう常識が何も通じない位違う。

効率はいいけど、既に何年も動いてるシステムだと変える気なくなるし、

変えない方がエンジニアにとっても優しいという現実が多々ある。

http://anond.hatelabo.jp/20100617154928

strutsがあるだけまだいーだろw

未だに大手企業システムはjdk1.3でhttpServletRequestの受け渡しでゴリゴリ書いてるよw

フレームワークなにそれ?って感じ

レガシーアーキテクチャ

未だに職場Struts

いちおー Spring とか Hibernate とか使ってるけど、一昔前のアーキテクチャって感じ。

LL だけが全てじゃないが、生産性では明らかに見劣りするようになってきた。

いい加減なんとかならんもんかなー。

まさか今更 struts-config.xmlゴリゴリ書くハメになるとは。

意外とこーゆー会社って多いのだろうか?

2009-07-08

今話題のポケゲーと昔、話題になったマージュとの関係

UserAgentなしでアクセスすると。。

http://marj.jp/

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented
it from fulfilling this request.

exception

javax.servlet.ServletException
       at org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:545)
       at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:486)
       at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
       at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
       at com.hmsystems.common.struts.extension.HmsActionServlet.process(HmsActionServlet.java:28)
...

http://pkga.jp/

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented
it from fulfilling this request.

exception

java.lang.NullPointerException
       at com.hmsystems.sns.presentation.struts.RequestProcessor.processForwardConfig(RequestProcessor.java:91)
       at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)
       at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
       at com.hmsystems.common.struts.extension.HmsActionServlet.process(HmsActionServlet.java:28)
       at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:696)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)

両方ともHM SYSTEMSさんが作っていたんですね。

http://www.hmsystems.com/

http://www.youtube.com/watch?v=k6_1P2EKKYo&feature=PlayList&p=56E3E51E650A4CE7&index=0

2009-02-19

モダンPerl入門』を第1章だけ読んだ

巷のPerl Mongerな人たちの間で話題の『モダンPerl入門』を読み始めた。

第1章はオブジェクト指向トレンドの話で、とても興味深く読んだのだが、同時に「なんでこれPerlで実装せなあかんの?」と疑問に思った。ていうかオブジェクト指向やりたいならJavaC#でいいじゃん。

Perl5には本格的なOOPの仕組みが実装されていない。

継承という基本的な概念もないし、コンストラクタなんかも用意されていない。ゆえに、MooseとかのCPANモジュールを使って実装しなければいけないのだけれど、その分敷居が高くなって初心者には判りづらい。初心者でも現場に投入できるような、強力なオブジェクト指向機構が用意されているJavaC#といった言語StrutsASP.NETといったフレームワークなんかとは全然違う。

私はメインPHPASP.NET(C#)という人間で、Perlバッチプログラムとかクローラの実装とか雑用処理なんかに使っている。PHPは小規模プロジェクトアジャイルな開発がしたい時、ASP.NETは大規模プロジェクトに呼ばれた時用の懐刀という感じで使い分けている。PerlWebサービスを作ることももちろん出来るけれども、どちらかというとスピードが優先される開発に用いるものだと思うし、OOPを用いた大規模なプロジェクトPerlを使おうとする理由がよく判らない。無駄に難しいし、そもそも本書を読めるレベルPerlを理解している人の頭数がかなり少ないだろうから、実装しても保守コストがやたらかかる。Livedoormixiはてなのような大規模サイトPerlで動いているようだが。。。

モダンPerl入門』は内容も書き方も素晴らしい良書だけれど、その辺りが引っかかった。「PerlOOPを使う理由(APS.NETStruts+Java採用しない理由)」は何なのだろうか? 私のプログラマーとしてのスキルが低いだけだと思うが、よく判らないので誰か教えてくだしあ。教えてダンコーガイ

2008-11-19

http://anond.hatelabo.jp/20081119000921

ほぼ年齢が変わらん増田です。こんばんわ。

あなたは贅沢を言ってますよ。正直自分ファイル構成を書いて、コンパイル環境テスト実行環境サーバー立てだって大変なのにチームでやるとなるとはっきり行ってああいう統括してくれるものがないと無理です。少なくともマッピング書いてみんなが理解してくれるのは物凄い事ですよ。

ずっとWeb何それおいしいの?っていう、過去の遺産を改修していく部署につっこまれてたので最近になって初めてStrutsとかTomcatとか触って感動

なんて管理が楽なんだろう。開発環境作るのにこれだけでいいなんて!

と、素で涙が出そうでした。チーム間のやり取りも良好です。

ま、やめるんだけどね。

最初からこの部署にいたら幸せだったろうなと本気で思う。

教えてくれ!Webフレームワークって本当に便利か?

ちまたじゃ、みんなフレームワークのことを当たり前のように論じててすごいなーと思うんだ。尊敬するぜ。だから、ミーハーなオレもフレームワークが気になって仕方ない!

だから、30歳近いプログラマのオレがプライドを捨てて優秀なハテナ住人に聞くが、

Webフレームワークって本当に便利か?

バカなオレだけど、MVCパターンが良い事は理解できるよ。

だが、そこまでだ。

Javaだと、StrutsSpringSeasarWicket等をよく目にするけどよぉ、ドキュメントの量どんだけだよ。

入門ドキュメントだけ見ると簡単そうに思えるけど、仕事で使えるレベルまで理解が深まるまでどんだけ時間かかんだよ。

起動遅い、動き遅い、定型パターンを外れたら、やる方法が見つかんねー。

で、苦労して作ってもよぉ、結局は、HTMLがピロッって出力されるだけで、見てくれが変わるわけでもなく、全然努力が報われん。

これって、どゆこと?

Servlet+JSP+簡単なライブラリ 程度で十分じゃね?

PHPだと、Zend FrameworkCakePHPsymfony等をよく目にするけどよぉ、ドキュメントの量どんだけだよ。

入門ドキュメントだけ見ると簡単そうに思えるけど、仕事で使えるレベルまで理解が深まるまでどんだけ時間かかんだよ。

デバッガの使い方分かってねーオレが悪いとは思うんだが、開発効率悪いぞ。(フレームワーク以前の話だが…)

統合開発環境何使えばいいの?わざわざクラス名や関数名覚えてられんぞ。(フレームワーク以前の話だが…)

何で、拡張子変えたがる。何で、変なテンプレートエンジン使う。エディタ認識されねーから開発効率悪いじゃねーか。デザイナがコーディングした分かりくいHTMLコードをよ、何で編集してるわけ?

PHPフレームワーク使わない方が便利じゃね?

ついでに聞くけどよぉ、ORマッピングライブラリって使えるの?

確かに書くコード量は少なくなっていいんだがよぉ、目に見えて遅いと思うのはオレだけか?

ディスクアクセスは明らかにボトルネックになるのに、巨大なライブラリコードを毎回走らせるんだよ。普通サーバじゃ余裕なの?

話題がそれたが、

Webフレームワークって本当に便利か?

実は、みんな、上司や先輩に言われて使ってるだけなんじゃないの?

ハテナ住人の優秀なエンジニアは、どんな目的フレームワーク使ってんだ?教えて偉い人!

ま、誰も見ないんだろうけど。

2007-09-24

スーツ族とかSIerとか言う人に対する愚痴

なんかまとまってないけど、書いたので乗せる。ほとんど愚痴だよ。

このへんからぼろぼろ出てきてるけど、まぁおおむね理解できる。

http://d.hatena.ne.jp/higayasuo/20070923

http://d.hatena.ne.jp/habuakihiro/20070922

http://d.hatena.ne.jp/jYoshiori/20070826/1188150596

 けどなんなだかなぁという気が最近している。

 スーツ族がつまらない連中代名詞であるのは良いとして、「スーツ族の煽りの結果、せっかくの良いものが台無しだぁ??」みたいな既定路線の論調はなんなんだろうという気になる。

 RoRでもStrutsでもなんでもいいんだけど「オープンソースの成果を世に普及させたい」とか、「俺の仕事場で楽しく使いたい」というのならば、道具としては工業製品としての品質を持っていないと駄目なんだけどって言いたい。

 で、また特有の色眼鏡で「あーまたサポートがどうのとか、枯れてないと駄目だとか言い出したよー」って言われそう。そういうファクターも大切だと言いたいけど、ここでいいたい品質って言うのは、フレームワークが持っているべき「誰が使ってもそれなりの物を作れる」っていう品質StrutsとかRoRが低い品質だって言いたい訳じゃない。素敵なフレームワークだと俺も思う。

けど、スーツ族とかSIer存在馬鹿すぎて駄目だとかそういうのはどうよと思う。

スーツ族とか頭の固いおじさん達の方がこのイット業界といえども圧倒的に多数なんだからそういう人たちでもうまく使えるようにするという進化を何度も繰り返すべきであり、その繰り返しは許容すべきモンなんじゃないだろうか。

 物理的な工業製品進化を見ても分かるように、「馬鹿でも使える」というキーワードはとても大切で、これは複雑さが人類史上maxソフトウェアといえども忘れてはいけないことの一つだと思う。「馬鹿でも使える」のを物理的な仕組み作りじゃ無理かもしれないということの解の一つとして「設定より規約」があるのかもしれないし、「いやいや、自動XML生成ツールで克服だよ」があるのかもしれない。

とにかく、そういった人たちの否定は、進化の否定、技術者としての自分の否定になるんじゃないだろうか。

あと、

スーツ族 == SIerコンサルタント

スーツ族 == ネット専業とかパッケージベンダーとかコミッタ

とかの文脈であって、たいていSIer中の人間は馬鹿にされがちだけど、SIerの中にもコミッタは当然いるし、理解が深いのも多いよって言いたい。 逆にSIerで、技術専門職である人間(業界専業のSEだとこの話の対象から外れるが・・・)の場合、千差万別のシステムを見てるので、尋常じゃない位の知識量と技術力が蓄積されている。

 そういう人たちが大規模なシステムを組むときに、普通プログラマ達がそれなり作ってそれなりの品質になるように苦心するわけ。上に挙げたようなエントリを書く人やそれにbookmark入れてコメントするような意識の高い人たちばかりだったら、理想郷になるんだろうけど。。。

2007-06-22

Re: ほんとのプログラマーを募集

これは…ひどい…

そもそも勉強会Strutsというあたりで既に身の程知らず感がひしひしと出ている。しかも書籍

俺はプログラマ脳なので、プログラマの考えることしかわからんが、そいつらに言っておいて欲しいと思う。

プログラマは、プログラムに何ができて何ができないのかわかってなくて、小さなプログラムすらきちっと仕上げられない奴の立てた企画に全力を投球することはない。また、仮に全力投球したとすると、その企画野郎からみると全力で妨害をしているようにしか見えないだろう。外注費も期間も膨れ上がること間違い無しだね」

プログラミングが若いののやるしょぼいことだと考えているのなら、大間違いだ。

企画や営業は、猛獣使いだ。

企画がまずくてもプログラマが働いてくれることがあるのは、解決すべき問題が美味しそうだからであって企画が上手だからとか偉いからではない。

猛獣になめられたら鞭打ったって動かないし下手すりゃ逃げだしたり頭からかじられたりするよ。

まあ、この増田さんは重々承知なんだろうけれども。

そんな奴らが部下だったら俺仕事させないなあ。

物凄い簡単なプログラムを書かせて、満足行く出来になるまでずっと直しを命じるね。しかもはっきり言ってしまうよ。

「お前たちは自分を有能だと思っているようだが、俺はお前たちが無能だと思っている。無能でなくなるための教育はするが、有能になるまで仕事には使えんし評価は最低をつける。昇給はないと思え」

だから俺は上司という仕事には向いていないのだけれども。

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