小手先エンジニア : Nothing is impossible
最近よく目にする「フルスタックエンジニア」とは何だろうか？ 以前なら(エンジニア)ゼネラリスト、最近はフルスタックエンジニアって呼ばれる類のエンジニアの需要というのは年々高まりつつあります。 ネットワークとサーバがわかってミドルウェアがわかって設計ができてコーディングができてUIも作れてデプロイまでできる。 これは確かに最高です。 わたしはUI周りに弱い、具体的にはJSとCSSに弱いのでそこもカバー出来る人はいいなあと思います。 なにせ一人で公開できるサービスが作れますからね。 UIがカバーできないとプロトタイプというかスケルトンで止まってしまいますw しかもクロスオーバーした技術をもっているということはそれだけで造詣の深い設計が出来る可能性があります。 ところがここに罠が一つあります。 まだまだ未熟なエンジニアが「よーし」とかいってそういうのを目指してしまうと、ただ使い
「CIを半年間まわしてみて」というお題でLTをしてきました - kaz29
大分時間も経ってしまい今更ではありますが、先日行われた第67回 PHP勉強会で「CIを半年間まわしてみて」というお題でLTをしてきました。 昨年の11/30に、当時ちょうど開発が始まった案件の開発環境に関して「今時なCakePHPでの開発環境！？」というエントリーを書いて、初のホッテントリ入りしました。4月末でこのプトジェクトが始まって半年という事で、実際にCIをまわしている中で起こった事や、試行錯誤しつつどうやって解決したかなどを簡単にまとめてお話ししました。 LT用に作った資料ではちょっと伝わりにくいので、以下にまとめ直しました。 成長の軌跡 Jenkinsサーバーを立ち上げた時は、UnitTestのテストケースが10個だけだったのですが、4/30現在 UnitTestのテストケースが467件、受入れテストのシナリオ数が292件とものすごい成長っぷりです。 この半年間に起こった事 テス
“GIGSI”CASE OF CLASSMETHODを開催しました！！ | DevelopersIO
クラスメソッドブログ課外授業7日目 こっ！これが今のSI人気なのか！？JS、AWSの勉強会などは初日で定員が埋まるのですが、定員の半分ちょいでした。。。しかし、内容は盛りだくさん！！ 1時間目：Process Framework CYCRONE ～デザインから駆動するシステム開発～ 1時間目は、take3000によるビジネスの課題と、デザインに対する要求、そしてテクノロジーによるソリューション。これらを調和させるクラスメソッド流のシステム開発の話でした。発表したスライドは以下になります。 小さめのツボをこしらえる嵩原先生。小さめのツボをつくりながらプロジェクトについて語っています 2時間目："GIGSI" CASE OF CLASSMETHOD 2時間目は、おおはしりきたけによるクラスメソッドのSIの仕方についてです。発表したスライドは以下になります。 大きめのツボをこしらえる大橋先生。大
同僚の外国人プログラマ観察記録 - rinu's blog
概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性 仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、 Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きな食べ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚の Windows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境は mac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。 PC スペック マシン: Macbook Pro メ
【資料公開】ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜
みなさんこんにちは。@ryuzeeです。 2013年2月15日に目黒雅叙園で行われたデブサミ2013で登壇してきましたので、その際の資料を公開します。 「いつまで手でデプロイしてるんですか？」ってキャッチーなタイトルにしたのは、公募セッションの申し込みの時に目につくようにしたかったためで、会場でアナウンスしてくださる方にこのセリフを言って欲しかったわけではないので念のため。 デプロイの自動化を進めていくのは正直なところ大変です。 今の現状からいきなり明日デプロイを自動化できるわけでもないし、誰かがいきなりデプロイを自動化してくれるわけでもありません。 その前に考えなければならないこともたくさんあると思います。 でも現実にAmazonやFlickrを始めとしてそれを実施している会社は多数あるし、日本にもそういう会社は多数あるわけです。ちょっとずつカイゼンしながら本当に利益に繋がるところに時間
現代のソフトウェア開発で構成管理が重要になった理由 - プログラマの思索
プロジェクト管理ツールBacklogを作っているヌーラボ社の開発者が書いた記事「現代のソフトウェア／サービス開発で構成管理が重要になった理由」がとても分かりやすいのでメモ。 構成管理がソフトウェア開発のサプライチェーンの一部になってきたのが原因ではないかと思った。 ラフな感想。 【元ネタ】 DevOps時代の開発者ための構成管理入門（1）：現代のソフトウェア／サービス開発で構成管理が重要になった5つの理由 (1/2) - ＠IT DevOps時代の開発者ための構成管理入門（1）：現代のソフトウェア／サービス開発で構成管理が重要になった5つの理由 (2/2) - ＠IT 【１】記事では、構成管理が重要性を増してきた理由として以下が挙げられている。 【1】簡単になってきたプログラミング 【2】クラウド（PaaS）の登場 【3】さまざまな用途のツールの進化 【4】ソフトウェアビジネスの移り変わり
特許庁：新システム開発頓挫 東芝子会社と契約打ち切りへ
特許庁は、特許や商標の出願情報を処理する新システムの現行の開発計画を断念した。受注した東芝子会社の作業が遅れ、続行は不可能と判断した。近く契約を打ち切り、入札をやり直す。開発にはコンサルタント会社分も含め５０億円超を支出しており、同庁は返還を求める方向で検討する。審査業務の迅速化につながる新システム導入が遅れる恐れもあり、専門家からは「日本の知的財産戦略に影響が出かねない」との声が上がっている。 新システムは、０６年に開発に着手し、３社による一般競争入札の結果、技術評価は最も低かったものの、予定価格の６割以下の費用を示した東芝子会社の東芝ソリューションが約９９億円で落札した。 当初は１１年１月に稼働予定だったが、０７年ごろから設計・開発が大幅に遅れ始めた。東芝ソリューションは１０００人超の体制で巻き返しを図ったものの、事態は好転せず、稼働予定時期を１２年１月、１４年１月、１７年１月と繰り返
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注
みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。ハードウエアの調達とアプリケーションの開発を分離し、さらに預金や融資といった機能ごとに開発委託先を変える。大手4社に発注を分散させることで、総額4000億円を超えるとみられる大規模プロジェクトにおける技術者確保などに万全を期す。 委託内容と発注先との関係は次のとおりだ（図）。勘定系システムの中核をなす「流動性預金」のアプリケーション開発は、富士通に委託する。富士通はみずほ銀が現在使っている勘定系システム「STEPS」の開発元である。 流動性預金のアプリケーションの動作プラットフォームには、日本IBM製メインフレームを使う。みずほ銀は「CIF（カスタマー・インフォメーション・ファイル）」や「処理フロー制御」など、各アプリケーション
設計と実装の狭間で - 急がば回れ、選ぶなら近道
・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず
エンジニアにスーツを着せているIT会社 - モジログ
私がよく通る道に古いオフィスビルがあり、そこの１階にＩＴの会社が入っている。看板に出ている社名と、窓からちょっと見える社内の雰囲気からして、古いタイプのシステム開発会社のようだ。その会社ではスーツ着用が必須のようで、全員スーツを着てＰＣに向かい、開発している。座席のレイアウトも昔ながらの「島型」で、向かいの人の顔が自分の視界に入るやつだ。私はこの会社の横を通るたびに、「ここの社員はかわいそうだなあ」と思う。 座席のレイアウトは、場所や予算の制約もあるだろうから、まあ目をつぶるとしよう。しかし、開発をするエンジニアにスーツを着せても、まるで意味がない。営業やサポートにも行くエンジニアや、客先常駐するエンジニアならまだわかるが、自社で開発しているエンジニアにスーツを着せても、仕事のジャマになるだけだ。 こういう古いタイプの会社は、経営者がおそらく「まじめに働く」ことを重視しているのだろう。みん
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
開発者にむけてDevOpsな現場で求められる「インフラがわかるデベロッパ」とは？ というテーマで話してきた発表した話 : インフラエンジニアに成る
テーマはDevOps。 Devが語るDevOpsはあふれておりますが、 Opsが語るDevOpsってないよね！っていうのが話の発端です。 この発想にいたった企画者の人がまあすばらしい。 いつも、お世話になっております。 DevLoveはあるのにOpsLoveはないよってことですよ。 すごいねこの視点。 それにのっかり、今回お話する機会を得ました。 結論としては、Dev and Opsでやっていきたいねという話！ 懇親会も大変もりあがりとても有意義な時間を過ごせて楽しかったです。 自分の発表内容に不安もありましたが、よかったよの一言をいただけて自信になりました。 以下、つらつらと。 いつものように覚えている言葉を文章化。 ・プログラマの時代。コードの時代。 2012年感じるのは、ほんとプログラマさんの時代だなって思います。 ツールはどこからくるのかといえば、Dev。 それにのっかるOpsとい
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
［CEDEC 2012］「ドラゴンクエストX」における開発進捗管理法とは？ セッション「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」レポート - 4Gamer.net
［CEDEC 2012］「ドラゴンクエストX」における開発進捗管理法とは？ セッション「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」レポート ライター：大陸新秩序 2012年8月20日から22日にかけて，神奈川県内のパシフィコ横浜にてCEDEC 2012が開催されている。本稿では，開催初日に行われたセッションから「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」の模様をレポートしよう。 「ドラゴンクエストX 目覚めし五つの種族 オンライン」公式サイト スクウェア・エニックス 開発部 ドラゴンクエストＸ デザインセクションマネージャー 荒木竜馬氏 本セッションの講師を務めたのは，スクウェア・エニックス 開発部 ドラゴンクエストX デザインセクションマネージャー 荒木竜馬氏だ。荒木氏は，「ドラゴンクエスト」シリーズや「FINA
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
クソゲーを作る組織とそうでない組織 2012 05-12
dots. ゲーム部での発表スライド なんか文字が表示されないのでこっちに上げました。 https://speakerdeck.com/toshi_k/kemuye-jie-tesi-u3tufalseda-shi-nakoto-2016-06-28
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
ソフトウェア開発における多能工の問題 - 勘と経験と読経
ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェクトが大規模より中小規模・短工期にシフトしていることが、専門家(単能工)による開発を難しくしつつある状況も、開発エンジニアの多能工化を後押ししている。しかし、多能工によるソフトウェア開発はベストプラクティスかというと、そうではないと思う。多能工アプローチの問題点について考察して望まないと、思わぬところから足をすくわれる事がある。 なぜ多能工なのか？専門家(単能工)はなぜだめなのか？ ファクトリー型アプローチは一時期流行し、いまなお一定の価値をもってはいるが、ほとんどのアプリケーション・ソフトウェアの開発には、現在これよりも有効な手法が存在している。 ソフトウ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://ipf.redmine.jp/redmine/