タグ

ブックマーク / aike.hatenablog.com (10)

  • ベンチャー企業で社員として働くこと - aike’s blog

    つまり、GIGAZINEで働きたかったわけではなく、どこでも金さえもらえれば良かった、そういう人材を私は雇ってしまったのです。これが大きな間違いでした。 【求人募集】GIGAZINEのために働いてくれる記者・編集を募集します - GIGAZINE これまで何社かベンチャー企業で働いたことがあるので、GIGAZINEのこの記事はあーあるあるという感じ。決して特殊な失敗例じゃなくて多くのベンチャーがこういう状態だと思う。なので今回は経営者ではなく社員としてベンチャー企業で働くことについてちょっと書いてみます。 ■ベンチャーとブラック企業との違い ベンチャー企業は労働条件だけみるとブラック企業と大差ないところが多いと思う。ただ違いとしては、ベンチャーは環境を改善する意思があり、今はその途中ということ。ベンチャー企業が何よりも最重要視すべきことはつぶれないことで、そもそもこれができないことが多い。

    ベンチャー企業で社員として働くこと - aike’s blog
  • 無駄な詳細設計書を滅亡させるための処方箋 - aike’s blog

    昔は「詳細設計書なんてアホなもん作ってもプログラミングには何の役にも立たないんだよふぁっきゅー!」と言い続けるのが、詳細設計書を滅亡させる手段だと思っていたけど、どうも事態はそんな簡単じゃぁないっぽい。 じゃあ一体どうすればいいのかってのはマッタク思いもつかない。まぁカンタンに無くなるもんだったらとっくの昔に滅びてるわけだしねぇ……もし、解消することが出来たら、ないし処方箋を思いつくことができたら、いつか blog に書きたいです。 詳細設計書が滅亡しない理由 - kagamihogeのblog SIerが作らされる詳細設計書(内部設計書とかプログラム設計書などと呼んだりもします)の評判は相変わらず悪いですね。このへんについては前からいろいろと考えてたことがあるので今回まとめてみます。コーディング時点で必要になる文書を極限まで減らしつつ、ウォーターフォール式の開発で納品物もきっちりそろえる

    無駄な詳細設計書を滅亡させるための処方箋 - aike’s blog
  • 荒れないウェブサービスの作り方 - aike’s blog

    ウェブサービスの運営者はどこも同じような悩みを抱えています。 ユーザーは基的にコミュニケーションが大好きなのですが、コミュニケーション機能は常に荒れる危険を伴っています。そのためウェブサービスはどこも工夫を凝らしてフレーム(flame)対策をしています。今回はいくつか典型的なフレーム防止のパターンをまとめてみました。 ■文字数を制限する 長い文章を投稿できると議論がフレームに発展しやすいため、書き込める最大文字数を制限する対策です。Twitterの140文字という制限は有名ですし、クックパッドの「つくれぽ」はわずか32文字です。pixivのコメントは255文字で比較的多いものの、改行ができないため長文は書きづらくなっています。長文を投稿したいというユーザーからの要望は強いはずですが、これらのサイトはしっかりとポリシーを持ってあえて文字数制限を設定していると思います。 ■コミュニケーション

    荒れないウェブサービスの作り方 - aike’s blog
  • ロジックをDBMS側に寄せるデザインパターン - aike’s blog

    O/Rマッパー(ORM)かSQLか、という話が一部で盛り上がっていたので追いかけていました。 ORMについては以下のような見方をすることもできます。 「最初からあらゆる要素をオブジェクト指向で設計、実装すると決めた新規開発システムならばORMは有力な採用候補」 「非オブジェクト指向で設計、実装されたシステムにORMはあまり向いていない」 なので、すでに存在しているデータベース上で別の新しいシステムを構築するような場合は、ORMはあまり向いていないと思います。 O/Rマッピングツールに対する誤解をときたい - ITは芸術だ 引用したエントリはとても冷静にORMの利点を説明している良記事です。 この記事の内容には全面的に賛同しつつ、自分としてはSQL側からちょっと書いてみたいと思います。 以前、試しにクエリに付随するロジックをできるだけDMBS側(SQL)に寄せるようにして開発したことがありま

    ロジックをDBMS側に寄せるデザインパターン - aike’s blog
    imai78
    imai78 2010/07/18
    [o/r mapper][architecture]
  • 架空の業務システム作ってSIer釣ろうぜww - aike’s blog

    みたいなウェブ広告が出ていました。 こんな感じでシステムを開発するのかと一瞬目を疑いましたが、たぶん違います。 1 :以下、名無しにかわりましてVIPがお送りします :2010/07/12(月) 03:06:26.90 まずは、システム名 >>10 2 :以下、名無しにかわりましてVIPがお送りします :2010/07/12(月) 03:07:42.12 システム要件 >>20 開発言語 >>30 3 :以下、名無しにかわりましてVIPがお送りします :2010/07/12(月) 03:08:12.48 受注金額 >>40 開発人員 >>50 920 :以下、名無しにかわりましてVIPがお送りします :2010/07/16(金) 23:22:52.30 後から判明する重要な要件 >>950

    imai78
    imai78 2010/07/14
    ほんとにあったら面白いwww
  • 『数学ガール』はソフトウェア技術者のおっさんが読むべき - aike’s blog

    遅ればせながら『数学ガール』の最初の話を読んだので、思ったことを書いてみます。 ソフトウェア技術者をやっていて、数学的な知識が必要になることが時々ある。そんなわけで、数学については以前から勉強しなおしたいと思っていたけれど、なかなか良いテキストに出会えなかった。高校生の受験対策テキストはターゲットがピンポイント過ぎるし、かといってオイラーやラマヌジャンがいかに超人だったかみたいな数学エッセイもちょっと違う。『数学ガール』はそんなソフトウェア技術者が数学に再挑戦するきっかけになり得る小説だ。 数学って不思議な学問で、誰もが数学に対して挫折感を持っているように見える。普通の人は高校数学くらいで挫折して、理系の人は大学数学で挫折して、数学課の人も博士課程あたりで挫折している。他の国語や社会のような教科ではそんなことはない。たとえ専門家よりもはるかに知識が浅いまま学校を卒業しても挫折感は持たない。

    『数学ガール』はソフトウェア技術者のおっさんが読むべき - aike’s blog
  • 十年前「はやぶさ」開発の現場を見ていた - aike’s blog

    小惑星探査機はやぶさ帰還のインターネット中継を見た。あのMUSES-Cが当に打ち上げられ、様々な困難を乗り越え、六十億キロもの想像を絶する距離を航行した後に地球に戻ってきた。わずかな時間ではあるけれどまわりを照らすほど明るく輝いて燃え尽きる映像を当に感慨深い思いで見ていた。 十年以上前、ぼくは横浜に住んでいて人工衛星の開発現場にいた。宇宙開発とは言っても設計業務はデスクワークであり、一見普通の会社とあまり変わらない光景だ。製造や試験は関係者以外立ち入らない別の施設でおこなうため、オフィスでは主にPCに向かって文書を作成している。 そこにいる技術者はみんな宇宙が好きということでは共通しているものの、担当部署によって少しずつ特徴があったように思う。熱設計、構造設計の担当者は特殊技能を持っている職人のようだ。データセンターで大量のデータ解析をする地上設備の開発者はIT技術者に近い。品質管理部

    十年前「はやぶさ」開発の現場を見ていた - aike’s blog
  • プログラマーが知っておくべきうつ病の知識 - aike’s blog

    少し前にITproにプログラマーは「こころの病」にかかる比率が高いという記事が載っていましたが、あらためて言われるまでもなくプログラマーがストレスで精神を病んで離脱するケースは自分の周りを見ても非常に多いです。こんな状況であればプログラマーに対する危険手当やプログラマー専用うつ保険とかあっても良いと思うのですがなかなか社会は変わらないようです。 このような状況に対抗するにはプログラマー自身が自衛のために知識を得ることだと思います。プログラマーの武器は知識であり、ハックする好奇心なのだから、あらかじめ十分な知識を身につけて不当なストレスに対して有利に戦いをすべきなのです。 1.判断力低下は想像以上に怖い うつで一番恐ろしいのは、気分が憂になることではなく、判断力が低下することです。 判断力が落ちるとどうなるかと言うと、自分が健康なのかどうか判断できなくなり、仕事を休むべきなのかどうかで判断

    プログラマーが知っておくべきうつ病の知識 - aike’s blog
    imai78
    imai78 2010/06/23
    自分が潰れないようにするのも大事だが、潰れてしまった時のことを知ってる事も大事。
  • 内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog

    数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発(内製)を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。

    内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog
  • スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記

    少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が

    スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記
    imai78
    imai78 2008/06/17
    いいえてみょう
  • 1