エンジニアとして大成したいならやってはいけない48ヶ条 - レベルエンター山本大のブログ
いろんなエンジニアを見てきて、成功パターンはそれぞれだけれど 失敗パターンはだいたい決まっている。以下、アンチパターン。 成し遂げるのではなく、中途半端で満足する。 自分の責任と考えず、人のせいにする。 よりよくしようとせず、現状維持を良しとする。 仕事を中心においていない。 自分の特徴を構築していない。同世代と比べてさしたる特徴がない。 生活習慣を重視しない。日々の積み重ねに価値をおいていない。 与えられたチャンスに乗っからない。やる前から怖じ気づく。 アウトプットの質にこだわらない。 自分を分析していない。強み弱みを問われても答えられない。 刺激よりも、平穏を求める。変化に弱い。 行動よりも熟考を優先する。考えた末に行動しない。 現在の仕事の進め方に疑問を持たない。既存踏襲が正しいと思っている。 チームへの貢献よりも、自分の仕事の進捗を優先する。 焼き畑農業的な人間関係。信頼の構築では
エンジニアにとって３５歳とは定年ではないが、真価が問われる時ではある。 - レベルエンター山本大のブログ
３５歳には３５歳なりの成長の仕方というものがあります。 ３５年、着実に１年１年、前に進んでいる人と、 確実にどこかで足踏みしてたなぁという人は、はっきりとわかってしまいます。 年齢というのはただの数字だけど、数字には魔力のようなものがあります。 というか、単純でわかりやすいということだけなんだけど、 その人が生きてきた成果と比較するための基準値といいましょうか。 ３５歳と聞くと、 ちゃんと向上心を持ち続けて生きてきたのか、適当に流されて生きてきたのかを どうしても見てしまいます。 ３０歳前後のエンジニアの皆さんに言います。 飛びぬけて技術に自信がある人以外は、 少しでも「リーダー経験」を積んでおきなさいよ。 本当にそこが一番重要だから。 一番汎用的なスキルだから。 人を動かせてなんぼですから。 人が作った土壌・枠組みの上で設計や実装をした経験の多さは、物の数ではないのです。 リーダ経験とい
はよプログラマとかエンジニアとかから脱却せんかい。 - レベルエンター山本大のブログ
プログラマの誇りがどうこうと書いていていうのもなんだけど、 プログラマが下手に誇りを持ちはじめた昨今。 いい加減、うんざりしてきた。職業ぷろぐらまな面々に。 作る技術がスキルのすべてだと勘違いしてるぷろぐらまに。 誰をターゲットに吠えるわけではないけれど、 我慢してることを言います。 仕事＝きれいなコーディング 仕事＝疎な設計 仕事＝きれいなドキュメント とか、そんなことで満足してんなって。 作る技術をバックボーンにして、 話をまとめる力をつけて、 要件をまとめる力をつけて、 交渉をまとめる力をつけて、 費用抑える力つけて、 お客さんの要件を引き出して、実現して、貢献して、 初めて仕事が成り立ってるんだろうが、 ビジネスが成り立つんだろうが。 目指さんかい、営業からテストまで1人で全部実現できるぐらいの境地を。 一周して来いって。 それができるまではずっとワーカー。 #追記 ワーカーは煽り
新しい環境へ踏み込む人に1つだけ必要な心構え - レベルエンター山本大のブログ
今日必要なのは今日を乗り切る勇気だけ。 明日のことは明日の自分に任せるだけ。
なぜ依然としてウォーターフォールが残っているのか？ - レベルエンター山本大のブログ
マネージメントに携わるようになってウォーターフォールにも理があると思うことが多い。（もちろん最適解ではないが。） ウォーターフォール・反復に次ぐ、実践的な開発プロセスを検討したいとずっと思ってる。そんな検討をしていこうと思う。 ということで、語りつくされてはいるが「アジャイルかウォーターフォールか？」から考える。 アジャイルかウォーターフォールか？ アジャイルプロセスが提唱されてから既に数年、業界の多くの著名人がアジャイルを推奨し、多くの書籍が揃う。 アジャイルの考え方は、ウォーターフォールプロセスによる開発で「仕様変更」と「コストオーバー」、「スケジュールオーバー」に苦しめられてきた開発者達の、怨念にも似た声から生み出されたものだ。 エンジニアの視点から考えると理想的な開発の進め方のように思う。 しかしながら、やはり実際の開発現場は依然として、ウォーターフォール式の開発プロセスを採用する
jQueryを使う7つの理由 - レベルエンター山本大のブログ
JavaScriptに本腰を入れ始めて日が浅いのですが、よく悩むのは、どのライブラリを使うか？です。 とりあえずナマのJavaScriptだけでゴリゴリ書くのはちょっと限界があるので、 ライブラリを使おうと思うのですが、一度ライブラリを決めると 他のライブラリに乗り換えるのは難しいように思います。 いろいろ調べて、結局jQueryにしようと思います。 やっぱり流行るだけことはあるなぁ。 【jQueryを使う7つの理由】 1.prototype.js などと混ぜて使える 標準では $ にショートカットが割り当てられるのですが、jQuery.noConflict()と書くことで prototype.js などと混ぜて使えます。 ウノウラボ Unoh Labs: JavaScriptライブラリといえば jQuery（入門編） 僕の場合は、意外とこれは大きい理由になりました。 prototype.
ルールを徹底する4つの原則 - レベルエンター山本大のブログ
以前のエントリ(ルールメーカーの生産性は、96倍 - 山本大の日記) に対して、コメントをいただきました。 今のPJでは、アサイン当初、まともなルールが無いPJでした。 「おいおい、こりゃまずいんじゃない？？」と思い、 自分が色々とルールを決めてみんなに提示したりしてました。 その結果… ・そのルールに欠陥(抜け)があって、バッシング ・メンバ内で徹底されず、逆に面倒な事に こんな状態でした。 ルールを作り出す事は重要だと思いますし、 必要だと感じれば、柔軟にルールを変える事は大賛成です。 でも、それを周知に徹底させて、実践し、推進していく事も同じく重要だと思わされる事が 今のPJではかなりあります。 周知に徹底させる為には、何が必要でどうすれば実践されると思いますか？ これには僕も覚えがあります。 一例を挙げると、僕が今の会社に入る前、仕事上のやり取りをルール化しようと考え 社内でコミュ
Java with CGLIB でC#ライクなDelegateを使う。 - レベルエンター山本大のブログ
Javaの言語仕様には、C#で言うDelegateは無いが、 CGLIBでDelegateの仕組みが提供されている。 C#にインスパイアされて作ったって書いてた。 Delegateというのは、（御幣を承知で言えば） メソッドへのポインタをオブジェクトインスタンスから切り離して 参照型変数に保持して利用するというもの。 継承なしでテンプレートメソッドが利用できるので、制御の反転がより柔軟にできる。 C#ではイベント処理に使われる。 やってみよう ■CGLIBのサイト http://cglib.sourceforge.net/ とりあえず、CGLIBをダウンロードする。 ASMという別のライブラリに依存しているが、 cglib-nodep-X.X_X.jarを使えばこれ一つで動く。 僕はBetaは使わず以下のものを使った。 cglib-nodep-2.1_3.jar まずは、Delegateを
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
