タグ

engineerに関するs17erのブックマーク (37)

  • プロとしての行為 Act as Proffesional

    事を抜く、おざなりにする 朝、昼、夕を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず事をとること。事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな?とあれもこれもと手を出すうちに2,3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか?QAやテストやドキュメントなどはいりませんか?誰に承認をえるのですか?これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。当に足りないことはあ

    プロとしての行為 Act as Proffesional
  • プロとしての行為 Act as Proffesional

    僕が新社会人になったときには、「このを読んで学ぶと良いよ!」なんて、紹介してくれる先輩がいなかった。 だから、無駄な書籍を読んで、あんなクソな読んでる暇があったら、この読んでおけば良かった。と、何度も思った@HIROCASTERでございませう。 新社会人の皆様に技術書は高価なので、厳選してオススメを紹介します。カテゴリ・言語別で上の方に並んでいる者が初級者にオススメ、下にいくほど、上級者向けです。数ヶ月かけてステップアップすれば良いのではないでしょうか。 新しいプログラマの教育担当者やメンターになった人は、この記事を教えてあげれば良いんじゃないかな。

    プロとしての行為 Act as Proffesional
  • 自身の生存を決定付ける「速さ」という要素 | F's Garage

    今週末に仙台のイベントでしゃべるのですが、そこでしゃべろうかな?!と考えてる、思考メモを公開しておきます。まだちょっと難しいので、もっとブレークダウンするつもり。 2/15(仙台)藤川真一氏講演「エンジニアが今後生き残るためのキャリアデザインとWebサービスサバイバル術」 トム・デマルコのにあった話だと思うけど、「品質」「納期」「仕様」は、それぞれ相反の関係性になっていて、どれか1つを優先しすぎると、残りの要素とのバランスが壊れるということは広く知られている。 「仕様」と「納期」が適切だったとして、実際にやるエンジニア、制作者が評価されるためには、もっと単純なところにパラメータを置いてみたほうが良い、と考えてみる。 そこで、品質と速度のバランスだけに絞り、 「速さを追求したものは美しい品質のものができるハズ」 という理想に対する現実の選択肢を考えてみる。 「スピードは早いが、コードは汚い

    自身の生存を決定付ける「速さ」という要素 | F's Garage
  • 一生、エンジニアであり続けるために必要なこと #e35

    まとめました。 masuidrive&吉田パクえ氏と考える「一生、エンジニアであり続けるために必要なこと」 : http://atnd.org/events/47239 -- 「エンジニア35歳定年説」というお題がありますが、これはエンジニアは「ずっとコードを書いていたい」「やりたいことを続けていたい」人種であることの裏返しともいえる表現だと思います。今回のセミナーでは、昨年末にメディアで自分自身のエンジニアとしてのキャリアを熱く語った2人のエンジニアの生きざまを通じて、「エンジニアとして生き残り続けていくには何が必要なのか」に迫ってみたいと思います。 -- 続きを読む

    一生、エンジニアであり続けるために必要なこと #e35
  • エンジニアを頑張ったで評価する会社は衰退する | rake enjoy

    この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。(最近のゲームなどは除く)またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を

    エンジニアを頑張ったで評価する会社は衰退する | rake enjoy
  • 「使う」から「公開する」へ

    この連載では、オープンソースソフトウェア(OSS)を使うだけでなく、自ら公開することのメリットを紹介し、1人でも多くのエンジニアの方がOSS界へデビューしていただけるよう支援します。レッツ、OSS! はじめに――オープンソースソフトウェアは「使う」だけ? 今では考えにくいことですが、かつてオープンソースソフトウェア(以下OSS)は、「無料で公開されているソフトウェアにはどんなウイルスが紛れ込んでいるか分からない」「障害発生時に責任を担保できない」といった考えから、利用を敬遠する企業が少なくありませんでした。 しかし今では毎日のように、大規模なOSS利用事例や新しいOSS製品がニュースをにぎわせています。OSSは情報系/基幹系、B2B/B2Cを問わず、システムに欠かせないものとなりました。これは、OSSの進化やバグフィックスの早さ、コードが多くの目にさらされておりセキュアであること、コスト削

    「使う」から「公開する」へ
  • [対談]ひがやすを×和田卓人×Yoshiori(1/3) 「プログラマー35歳限界説」との上手な付き合い方って何だろう? - エンジニアtype

    株式会社ドワンゴ ニコニコ事業部 ニコニコ静画(電子書籍)システムリーダー Yoshiori(庄司嘉織)氏 [@yoshiori] Javaコミュニティ『java-ja』代表として知られるプログラマー。ヘルプデスク業務などをこなした後、25歳から格的にプログラミングを勉強。その後、ひが氏との出会いから『java-ja』を立ち上げる。2009年からドワンゴに勤め、現在『ニコニコ静画(電子書籍)』の開発リーダー ―― 前回の座談会で、「ある程度の年齢になると、外的環境が変わって仕事の進め方が変わる」というお話が出ました。そこで今回は、「プログラマー35歳限界説」をテーマにお話しいただこうと思います。ところで、皆さんはおいくつなんですか? Yoshiori オレ、今は36歳ですね。今年で37歳になっちゃいます。 ひが 僕は43歳だね。今年の誕生日で44歳になる。 和田 わたしはまだ34歳です

    [対談]ひがやすを×和田卓人×Yoshiori(1/3) 「プログラマー35歳限界説」との上手な付き合い方って何だろう? - エンジニアtype
  • 『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』に参加してきた #devlove - Diary of absj31

    SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - DevLOVE 2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove - Togetter 講師及びその講師の方が話されるテーマも相俟って、募集後即定員が埋まる盛況振り。自分もタイミングを逸しキャンセル待ちで登録していたのですが、晴れてキャンセル待ち繰り上がりで参加資格を得る事が出来たのでこの日参加して来ました。 会場はマイクロソフト品川社セミナールーム。今回はいつにもまして参加者も著名な方が多数参加。注目度の高さがここでも伺えます。 papandaさんの今回のイベント開催に至る経緯として以下の様なコメントが最初にあり、間髪入れずに編へGOです。 ブログを読んでいて、書かれている事が仕事に対して危機感を持つ内容だった。 こういった内容を書かれる方のお話を聞いてみたい。

    『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』に参加してきた #devlove - Diary of absj31
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type
  • #4 アナタに一番合うアイデアの生み出し方、育て方、ゴール─閑歳孝子氏、増井雄一郎氏 | gihyo.jp

    IT専門の人材サービス・アウトソーシング事業を行うパソナテックが6月1日、渋谷のコワーキングスペースLightningspot内にWeb制作やスマホアプリ開発、ソーシャルマーケティング事業を展開する「渋谷Lab(ラボ⁠)⁠」をオープンしました。記事では、オープニングイベントとして5夜連続で開催した「shibuya meets tech」イベントの様子を紹介します。 技術探究心、日々の些細な物足りなさ、自己表現など十人十色のモチベーションではじめるサービスやアプリ作りを成功させるためには、どういった着想や進め方、目標設定をすれば良いのでしょうか。 6月7日のshibuya meets techでは、株式会社ユーザーローカルの閑歳孝子氏とAppcelerator Inc.の増井雄一郎氏をゲストに招いて二人の経験を交えつつ、個人でサービスやアプリ作りをする際の勘所をディスカッションしました。

    #4 アナタに一番合うアイデアの生み出し方、育て方、ゴール─閑歳孝子氏、増井雄一郎氏 | gihyo.jp
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type
  • セミコン見ル野のシブすぎ技術に男泣き!|【Tech総研】

    元半導体エンジニアである理系マンガ家・セミコン見ル野が、全国のモノづくり現場を訪問。モノづくり立国ニッポンを支える技術者の熱い思いを伝えます。

  • 堀江貴文 エンジニアは誇り高くあれ|【Tech総研】

    東京大学文学部宗教学宗教史学専修課程中退。1996年に「有限会社オン・ザ・エッヂ」を設立。2002年に旧ライブドア社から営業権を取得し、2004年に社名を「株式会社ライブドア」に変更。2006年に証券取引法違反容疑で起訴されて一審、二審ともに有罪判決を受ける。現在上告中。1972年福岡県生まれ。 今、非正規雇用の増加やいわゆる「派遣切り」が社会問題になっていますけど、僕が前の会社(ライブドア)で社長をやっていたときは、技術者派遣やSI会社の常駐社員などは一切使わなかったし、逆に自社の社員を派遣することもしなかった。社内ではこうしたシステムを利用するようにかなり説得されたけど、ここだけは頑固に譲らなかった。 唯一、派遣会社を使ったのは受付の女の子たち。いろいろとあって押し切られてしまったのだけど、彼女たちが望めば正社員にしていたし、希望すれば総務や経理に異動もさせていた。ほかに社員でない人と

  • Webエンジニアスキルの勘所

    Webのエンジニアにはどういうスキルが一番必要か?という話を考えてみた。 例えば、C言語やUnixの経験が長く、オブジェクト指向も理解していたとしたら、PHPから始まり、Rubyなどの理解は決して難しくないだろう。 では、それだけの経験で一線級のWebエンジニアとしての信頼が置けるかというと、ちょっと違うような気がする。 考え方のベースは、 「Webは、要するにテキスト処理であることが多い。だから難しい」 ほとんどの事がHTTPプロトコルを通じてテキストデータとして情報が、なんのネットワークの制約もなく流通する。つまり、HTTPヘッダを含むテキストの操作でセキュリティホールを作り、それが世界のどこから攻撃されるかわからない。 また、 同様に世界中からアクセスが集まることがありうるので、回りくどいテーブル設計をしてしまうと、あっというまに破綻してしまうこともある。 そして、 基的にマルチア

  • マネタイズとアウトプットを意識する~エンジニアの視点から考えるネットサービス:エンジニアブレークスルー#02レポート | gihyo.jp

    マネタイズとアウトプットを意識する~エンジニアの視点から考えるネットサービス:エンジニアブレークスルー#02レポート エンジニアがどのようにしてブレークスルーしていけるか エンジニアブレークスルーは、その名のとおり「エンジニアがどのようにブレークスルーしていけるか」をテーマに、株式会社ゼロスタートコミュニケーションズ 山崎徳之氏を中心にスタートした活動。10月7日に、スタートアップデイティングの一企画として第1回が開催され、今回初の単独開催として、第2回目開催の運びとなった。今回は二部構成で、一部がパネルディスカッション、二部がパネリストと参加者の交流を兼ねたエンジニア査定大会が実施された。 イベントの企画者でもあり、モデレータを務めた山崎氏。 エンジニアの視点から考えるネットサービス 今回のパネリストは以下の通り。 米林正明 氏(株式会社Abby) 閑歳孝子 氏(株式会社ユーザーローカル

    マネタイズとアウトプットを意識する~エンジニアの視点から考えるネットサービス:エンジニアブレークスルー#02レポート | gihyo.jp
  • 仙石浩明の日記: パネルディスカッション ~CTO のから騒ぎ for the future~ に登壇しました

    先日開催された楽天テクノロジーカンファレンス2009 で、 パネルディスカッション ~CTOのから騒ぎ for the future~ にパネラーとして登壇しました。 他のパネラーはベンチャーの CTO の方々。 いずれも 「CTO サミット」 (という名の飲み会) で毎度ご一緒している皆さんなので、 飲み会と同様とても盛り上がりました。 モデレータの森さま (楽天技術研究所所長)、 どうもありがとうございました。 このパネルディスカッション (という名のビール飲みながら放談会, ただし私は飲めないのでウーロン茶) の議事録を書いてくださったかたがいらっしゃったので、 適宜引用しつつ感謝の意を表します。(_O_) まず冒頭の自己紹介の部分から: KLab 株式会社の仙石です。 就職してから 16~17 年。 卒業してしばらくはベンチャーに縁がない生活(論文書き)。 ある日突然転職することに

  • 身内同士で甘えているからエンジニア発サービスは大きくならない

    はてな界隈でちょっと名の知れたエンジニアが作ったサービスって必ず話題になる。 でもそれだけ。 話題になるだけ。 「~~さんが作ったサービス!面白い!」といろんな人が宣伝しまくるからはてブ数は飛躍的に伸びる。 でもそれだけ。 はてブ数が伸びるだけ。 結局身内同士で称賛しあってるだけで実際のサービスの質で勝負できてないんじゃないかな?同じ個人エンジニアが作ったからすごい!って言ってるだけで別にサービスの中身がすごいわけじゃないから数か月もすればすっかり使われなくなる。あるいはサービスに不具合や使いづらい点があったとしても「~~さんが個人でやってるから仕方ない」と周りが甘い目で見ちゃう。だからいつまでも改善されないし低レベルなままのサービスレベルで放置される。 実例を挙げると2007年~2008年頃のロケットスタートがわかりやすいのではなかろうか。ロケスタの棟梁id:kensuuさんといえば は

    身内同士で甘えているからエンジニア発サービスは大きくならない
  • すさまじく充実してる IT 勉強会カレンダー - てっく煮ブログ

    ここ最近、技術系の勉強会がものすごく多い印象がある。毎日どこかで誰かがやってるんじゃないの、と思ってたら、当にやっているらしい。これは id:hanazukin さんが Google カレンダーで運営中の IT 勉強会カレンダー。休日だけでなく、平日もぎっしり詰まっていて衝撃を受ける。例えば、今週土曜日は日全国で14個の勉強会が開催されるらしい。そんなにやってるのか!!勉強会名をクリックすると、場所と申し込みページが表示される。これはすごいといわざるをえない。あの勉強会の情報が載ってないよ!というのがあれば、id:hanazukin さんにメールすると記載してくれるみたい。伝えるときのガイドラインはIT勉強会カレンダーに情報を下さる方へを参照あれ。ただ、協力しようと思って探してみたけど、自分が知ってる勉強会は全部記載されていた…。すさまじい。ちなみに、新着の勉強会は こちらの RSS

  • KOF2009:関西オープンソース2009

    2009-11-08 すべてのプログラムを完了し、イベントは終了しました。参加してくださった皆様に感謝いたします。 2009-11-05 KOF開催中、マーレ広場にあるステージの模様などをライブ配信いたします。 2009-11-05 iPhone向けプログラムを作成しました。iPhoneをお持ちの方はご利用下さい。 2009-11-03 懇親会の申し込み受付を終了致しました。当日受付はお問い合わせ下さい。 2009-10-30 書籍情報として、ジュンク堂書店KOF店を掲載しました。 2009-10-28 インフルエンザ対策を掲載しました。ご来場の際はご一読願います。 2009-10-23 プログラムを公開しました。タイムスケジュールなども公開しています。 2009-10-16 ユーザ企画の申し込み受付を全て終了致しました。多数のご応募有難うございました。 2009-10-11 土曜のユーザ

  • UK STUDIO - Web系受託会社は亡びる

    やけに煽ってるタイトルだけど、別にそんな大した話でもない。最近個人的に思ってることをつらつらと書く。 まず、Web系受託会社の定義だけどまぁWebサービスやWebアプリケーションなど比較的規模の小さいものを受託で作っているところとする。「規模の小さい」も割と感覚的なものだけど、まぁその辺の詳細は省く。 で、なんでまた亡びるとか言いだしたのかと言うとこの程度の規模のものは外部に開発を依頼するより、自分達で作る内製に向かっていくんじゃないと思っている為。特に最近の不景気でエンジニアを雇って内部で作るという流れがあるように見える。少なくとも僕のまわりでは。現にそういう話で「うちこない?」的なことも何度か言われている。受託会社に勤めている身としてはうちに発注してよと思わなくもないが、なかなかそうも行かないらしい。 まぁ個人的にはWebサービス、アプリケーションに限らず、いわゆる業務システムも内製し