10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会
会社から「頼りにされる」危険性 - ひがやすを blog
エンジニアは、誰でも、人の役に立ちたいと思っているものです。そして、人から頼りにされることに、喜びを感じる生物です。でも、この「頼りにされる」状態は、危険な状態であることもある。 頼りにされるあまり、多くの仕事がその人に任されることになる。できる人に、仕事が集中するのは、よくある話で、その人は、回りの期待にこたえようとして、遅くまで残業して、休日も出社したりする。この状態が、一過性のものだったら良いんだけど、慢性的なものになると、肉体も精神もぼろぼろになっていく。 仕事が慢性的に過度に集中している人は、一度じっくり考えてみたほうが良い。会社は、「あなた」のことを頼りにしてるけど、実際のところはこき使ってるわけですよ。俺なら、ピンチのときにできる人に仕事をいっぱい頼むことはあっても、それを慢性的には行なわない。だって、その人に壊れて欲しくないから。 仕事が慢性的に過度に集中している人は、会社
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
上司に認めてもらえないエンジニアは“社内”を捨てOSSで行こう
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 比嘉康雄氏といえば、Javaのための「依存性の注入（Dependency Injection：DI）」と「アスペクト指向プログラミング（Aspect Oriented Programming：AOP）」をサポートした、フレームワーク「Seasar2」のチーフコミッターであり、日本のオープンソースソフトウェア（OSS）の世界でも有名人と言えるだろう。そうした比嘉氏がOSSに出会ったのは、「社内での評価に対する不満」がきっかけだという。 電通国際情報サービス（ISID）に勤務している比嘉氏は先頃開催された情報処理推進機構（IPA）のイベント「IPAフォーラム2007」の中で、「開発を夢のある仕事にするには」と題する講演を行った。同氏は、20
[Seasar Conference]「世界への普及目指す」---ひがやすを氏が新フレームワーク「Slim」を発表
「新しいカテゴリのソフトウエアとして位置付け，英語で情報発信して世界への普及を狙う」---ひがやすを氏は2008年5月24日開催されたSeasar Conference 2008 Springで新フレームワーク「Slim（Simple, Less is More）」を発表した。 Slimは，ひが氏が開発したJavaフレームワークSeasar2の機能を絞り込んでシンプルにし，習得しやすくしたものだ。Seasar2はDI（Dependncy Injection）コンテナと呼ばれることが多かったが，DIコンテナとしては海外ではSpringが普及している。Seasar2の特徴であるホットデプロイ（Webアプリケーション・サーバーを再起動することなくプログラムの修正を反映できる）機能を前面に押し出し「ホットデプロイ可能なフルスタック・フレームワーク」という，Javaでアジャイル（俊敏）な開発を行うた
![[Seasar Conference]「世界への普及目指す」---ひがやすを氏が新フレームワーク「Slim」を発表](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
女性にもてたい技術者のためのオープンソース開発 - ひがやすを技術ブログ
昔は、結構合コンやってたように思われる私ですが、20代のころは、全然もてなかったなぁ。何でかって? 顔がよくなかったと思う(笑)。これが昔の写真。 そしてこれが今。 結構違うね。もちろん、整形なんてしてないよ。 この違いは、オープンソース開発を始めたことにあると思う。 オープンソースの開発を始めると、知らない人といっぱい会い、知らない人といっぱいしゃべらなければいけない。これが、社交性を高め、社交性の高さが顔を変えていくんだと思う。 さらに大きなイベントでしゃべったり、雑誌やWebのメディアに顔が載るようになると、服装や髪型にも気を使い、さらにイメージが変わってくる。 人の顔なんてちょっとしたきっかけで、だいぶ変わります。 女性にもてたいと思っているあなた。だまされたと思ってオープンソース活動を始めてみてください。半年後には顔が(良い方向に)変わっているはず。 私が、髪をきっているところは
社内評価に不満の技術者こそ、外へ――Seasar開発者がメッセージ － ＠IT
2007/10/30 「偉くなりたい、金がほしいのではなく、自分のことを認めてほしいのがエンジニア。そのためには社外に出て行くしかないと思った」。オープンソースのJava軽量コンテナ「Seasar」の開発者で、電通国際情報サービスに勤める比嘉康雄氏は10月30日、「IPAフォーラム2007」で講演し、自身の経験から「エンジニアは社外に出て行くことで認められる」と訴えた。 社外に出て行かないとエンジニアは評価されない――比嘉氏がそう感じるのは自身の社内での仕事が正しく評価されていないと感じていたからだ。自身の仕事を社内にアピールできなかったことや、アピールしても仕事を上司が正しく評価してくれなかった過去のケースを挙げて、「技術者は社内で認めてもらうのが非常に難しいと思った」という。 技術者の仕事を評価するのは一般的にはその上司。しかし、管理が仕事の上司は最新の技術動向に詳しくなく、技術者が最
Strutsをなめんな - ひがやすを blog
リリースノートはこちら Bug [SASTRUTS-18] - ArrayWrapperでListを実装するようにしました [SASTRUTS-20] - ActionからActionへ遷移できない問題を修正しました Improvement [SASTRUTS-19] - ActionのプロパティがMapの場合も扱えるようにしました ダウンロードはこちら http://sastruts.seasar.org/download.html このバージョンから、チュートリアルに、ResourceSynchronizerプラグインを使ったリッチなエラーページをつけました。ResourceSynchronizerを超ざっくり説明すると、ブラウザからEclipseを操作するプラグインです。 チュートリアルのリッチなエラーページをクリックすると、Ext.jsで作ったリッチなエラーページが表示されます。ス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
