梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ
例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働
ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ
ぼくは水曜日にTokyo Cloud Developerの集まりに出た。 そこで、LLのひとから、「Google App Engineは、Python版以外にJava版も出たけど、サンプル見たけど、たくさんコード書かなければいけなくて、正直どこがいいのか教えて欲しい」という質問があった。 blogに名前を出していいかの了解を得ることを忘れたので、ここには、LLの人としか書けない。 ぼくは、そこで一言申し上げた。あるいはそれは、「申し上げた」というような生やさしいものではないかも知れない。端的な言い方をすれば、ガツンと言ってやった。 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒
java.util.Dateをjava.sql.Dateにきちんと変換する方法 - ひがやすを技術ブログ
多くの人はこうやればいいと思っているかもしれません。 java.util.Date d = new java.util.Date(); java.sql.Date d2 = new java.sql.Date(d.getTime());確かにこれでも一応変換はできますが、きちんと変換してはいません。java.sql.DateのJavadocを見るとこう書いてあります。 SQL DATE の定義に対応させるために、java.sql.Date のインスタンスでラップされたミリ秒の値は、インスタンスが関連した特定のタイムゾーンで時間、分、秒、ミリ秒をゼロに設定することで、「標準化」する必要があります。 つまり、java.util.Date#getTime()をjava.sql.Dateにただ渡すだけでは不十分で、「特定のタイムゾーンで時間、分、秒、ミリ秒をゼロに設定しなければいけない」のです。そ
0.5倍しかできないエンジニアが生き残る方法 - ひがやすを技術ブログ
だから私がもし本当に10倍パフォーマンスがあって志あって,真に自分のやりたいことのあるエンジニアだったら,会社には2倍程度のパフォーマンスだけ見せて仕事をこなしつつ,残りでほかのことすると思う． この話の前提には、仕事をどれだけこなすかという量が重要だということがある。 でも、量を誇るエンジニアは、会社にとって都合の良い道具に過ぎない。実際、パフォーマンスがものすごく優れた人がいても、会社はそれに応じた給与を支払わないだろう。 それでは、どういう人に会社はお金を払おうと思うだろうか。それは、その人の成果のユニーク性が高いとき。他の人にはできない成果を出してくれるから、そこに付加価値が生まれる。 代替不可であることが重要なんですよ。かわりはいないから、お金を払ってもらえる。代替不可な人間になることは難しい。だからこそ、価値が出るのです。 0.5倍しかできないエンジニアが生き残る方法も是非＞＜
「ずば抜けているコンプレックス」を克服する方法 - ひがやすを技術ブログ
404 Blog Not Found:それって勉強じゃないよ http://d.hatena.ne.jp/pollyanna/20081224/p1 なんかかみ合ってなくて残念だけど、弾さんは「天才コンプレックス」、pollyannaさんは「秀才コンプレックス」を持っているんじゃないかと思う。嫉妬の意味でのコンプレックスではなくて、「できる人」の悩みのほう。他人と自分のギャップに戸惑っている。 弾さんの「天才コンプレックス」については、この辺を見ると良くわかる。 私にとって、天才とは天災以外の何者でもなかった。かといって、「能ある鷹は爪を隠す」(これまた耳に胼胝が出来るほど言われた)というほど器用にもなれなかった。 pollyannaさんの「秀才コンプレックス」はこの辺。 それ以来、私には「頭のいい子」という称号がついて回った。 賞賛の意味でそう呼ばれることが多かったが、「変わってる」「す
華のあるイベントやりまーす - ひがやすを技術ブログ
以前予告した日本Javaユーザグループでクロスコミュニティカンファレンスの中身が大体決まったので、お知らせします。10/16の午後は空けておいてね。 タイトル:パフォーマンスチューニング入門 講演者:amachang 概要:IT戦士 amachang が日頃やっているパフォーマンスチューニングの方法を紹介いたします！ポロリもあるよ！ タイトル:ギークなお姉さん(仮) 講演者:べにぢょ、山田あかね タイトル:『JavaからRubyへ』・アンド・ナウ 講演者:角谷、高井、和田 概要:角谷がついカッとなって『From Java to Ruby』と題された書籍の翻訳をはじめてから2年が経ちました。『JavaからRubyへ』というバズワードは我ながらうまく状況をとらえたと思っていますが、書籍に書かれているのはあくまでも著者Bruce Tateの主張です。このセッションでは私たちそれぞれの立場と視点と
女子だらけの飲み会に参加して感じること - ひがやすを技術ブログ
私は正直、女子だけの飲み会のほうが怖い。 大学時代は、月2,3回、ワイン会(ワイン飲み会)に行ってたんだけど、ワイン会ってほとんど女子ばっかりなんだよね。後、10年くらい料理教室に通っているんだけど、料理教室も女子ばっかりです。 はっきりいって男子だらけの飲み会に参加するようになったのは、オープンソースをはじめてから。 そんな「女子だらけの飲み会」と「男子だらけの飲み会」の両方を結構の数体験している立場からすると、「女子だらけの飲み会」の方が気が楽です。 「女子だらけの飲み会」の場合、女子は(基本的に)何にも気を使わないんだよね男子に対して。好き放題にしゃべってる。話をちゃんと聞いて、飲み物や食べ物に気をつけていれば大丈夫だから精神的には結構楽。 話の中身は、怖かったりするのかもしれないけど、そこには、深く触れないから問題なし。 それに対して「男子だらけの飲み会」の場合、しゃべらない人が結
離職率の高さが人材を流動化させ業界が活性化する - ひがやすを技術ブログ
またアクセンチュアは「業界平均より離職率が高い」が、「IT業界内での人材の流動化は歓迎すべきことと考えている」と話した。IT業界でのキャリアパスには、コンサルタントやプロジェクトマネジャになるだけではなく、「ベンチャーキャピタリストになったり、アカデミックの道に進むなど色々な方法がある。さまざまな経験をした人材が転職によって交流することで、IT業界は活性化する」とした。 離職率の高さは、一見ネガティブに見えるけど、スキルアップを定期的に実感できるようにすることで、自分に自信をつけ、会社から卒業しやすくするってのは、良い考えですね。 社員にとっては、スキルアップで自分の価値を高められる。 一方、会社にとってもモチベーションの高い社員が一生懸命働くことで、生産性が高まり利益率も上がる。逆にモチベーションの低い社員は、止めざるを得ないようにきびしく競争させるんでしょう。 利益率が高いから、社員に
軸がぶれないって危険なことかもね - ひがやすを blog
「軸がぶれないことが重要」っていう人は、結構多いと思うんだけど、危険なことかもね。最初に決めたことがあっているならそれでいいけど、あってるとは限らないからね。 「だからこそ最初に良く考えるんだろう」っていいそうだけど、どんなに良く考えたって、間違いはある。人間は、未来のことはわからないんだから。 私は、XPのYAGNI(You Aren't Going to Need It)の考え方が好きです。「今必要のあることだけをやれ」っていう考えが。 「人は未来のことはわからないんだから、できる限りの予想をして未来に備えよう」ってのと真逆な考えで、「人は未来のことはわからないんだから、予想するのはやめちゃって、今必要最小限のことだけをしよう」ってことです。 そして、「現実にあわせて素早く舵を切る」のです。 私は、XPにふれて以来、ずっとこの考えに従っています。 先のことは予想しない。 現実にあわせて
嫁、妻、家内の正しい使い分け - ひがやすを技術ブログ
昨日のiPhoneが女性に受けない10の理由のエントリに「iPhone確かに買わないけど。なんかむかつく。」という女性のコメントがありました(今見ると消えてますね)。 なんか書き方悪かったかなぁとおもって、うちのかみさんに内容をチェックしてもらいました。かみさんからは、もしかすると、「嫁」という言葉のイメージが悪いのかもねというコメントをもらいました。確かに、「嫁」という漢字は女は家にいるべきだ見たいな印象を受けますね。 というわけで、嫁、妻、家内はどうやって使い分けるんだろうと思って、ぐぐってみました。 夫・主人・旦那、妻・家内・奥さんそれぞれの呼び方で何か意味があるのでしょうか 「嫁」と言う言葉の使い方 他にもいろいろな意見があったんですが、まとめると、こんな感じです。 嫁は、息子の妻をさすそうです。 知らなかった。使い方間違えてたよ。日本に間違った使い方を広めたのは、きっと、加山雄三
iPhoneは老害リトマス試験 - ひがやすを技術ブログ
この老害リトマス試験は、スーツな人もギークな人もスイーツな人も受けて欲しい。自分の老害危険度がわかるはず。 老害とは、「状況の変化を認識できず、古い考えを押し通し、回りに迷惑をかけること」。 詳しくはこちら。 SI業界の老害が若手と下請けを蝕む理由 日本版iPhoneのニュースを見たとき、あなたはどう思っただろうか。 「ぜひ欲しい」と思ったあなた。正常な反応だけど、「でも、それだけ?」 日本でiPhoneがどれくらい売れるのかを予想してもあまり意味がない。だって、神様でもない限り先のことはわからないんだから。 でも、これだけはいえる。 「iPhoneは新しいアプリケーションプラットフォームになる」 新たなアプリケーションプラットフォームの立ち上がりに参加できるなんてすごい幸運だ。スーツな人なら、新しいビジネスを考え付けば、大もうけできるかもしれない。 ギークな人なら、このわくわくするテクノ
10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
ダイコン時代の設計手法 - ひがやすを技術ブログ
スタラジで、本来話したかったことをまとめておきます。 最初はユースケースからスタートします。 本当は、RFPをユースケースに落とすという工程が 前工程にあります。 ユースケースの粒度について神経質になると 失敗します。 画面系ならいくつかの関連のある画面をまとめたものが 1つのユースケース。 ものすごく狭い言い方をするとメニューから呼ばれる 関連のある画面群が1つのユースケース。 帳票系なら1つの帳票が1ユースケース。 バッチ系なら関連するジョブをまとめたジョブネットが 1つのユースケース。 ユースケースを状態とサービスに分離します。 サービスはステートレスです。 状態は永続的な状態とプレゼンテーション層における一時的な状態に わかれます。 永続的な状態はER分析され、エンティティ(JavaBeans)にマッピングされます。 ここでは、UI層における一時的な状態を サービスから切り離し、サ
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
配偶者とフレームワークは現物を買え! - ひがやすを技術ブログ
今の彼氏は、一応エリートと言われる職種についているんですが、年収が微妙です。最終的には3000万くらいにはなるみたいですが、それってすっごいお金持ちってわけじゃないですよね？外資系の証券会社なら億単位で稼ぐ人もいるって聞きますし。どうしたらそうした人達と付き合えるんでしょうか？結構出会いは多いほうだと思うんですが、いつも想像したのより年収が低くてがっかりしています。将来、出世してお金を稼ぐようになる男の人を見抜くコツを教えてください！付き合う前から年収を聞くなんてことはできません。将来性をどうしたら見抜けるのでしょうか？ ちなみに二十歳の学生です。今まで付き合った人とは全員合コンで出会っています！出世している旦那さんや彼氏をお持ちの方がいたら、是非とも教えてもらいたいです。 これを見てむかついたあなた。わかります。でも、あなたも、彼氏/彼女/フレームワークを将来性とかで選んでませんか? は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
