タグ

ITと開発に関するblmk313のブックマーク (15)

  • テクノロジー : 日経電子版

    12月9日の米ハワイ州ホノルル市で、46回目となるJALホノルルマラソンが開催された。そのスタート地点に、4万2914番のゼッケンを着けたNTTドコモの吉沢和弘社長の姿があった。N…続き 「共通ポイント」獲得しやすく 併用対応の店舗増加 ポイント、投資の入り口に Tポイントで新証券会社 [有料会員限定]

    テクノロジー : 日経電子版
  • プロとしての行為 Act as Proffesional

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

    プロとしての行為 Act as Proffesional
  • サービス終了のお知らせ - NAVER まとめ

    サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。

    サービス終了のお知らせ - NAVER まとめ
  • 「SIerでのキャリアパスを考える」というイベントに登壇しました - GoTheDistance

    403 error - Forbiddenで発表させて頂きました。発表資料をSlideShareにあげました。ご自由にダウンロードしてください。 あと、当日は結婚のお祝いということでケーキを頂いてしまいました。ひがさん、山岡さん、笠木さん、ごちそうさまでした&ありがとうございましたー! SIerでのキャリアパスを考える発表資料 View more presentations from Michitaka Yumoto 15分では全然伝えきれなかったので、下記によくわかる解説を加えておきます。資料の向こう側にある背景を掴んでください。 何を話そうか最後まで悩んだんですが、今までブログで僕が問題提起しているSI業界構造の問題を再認識してもらい、「問題が問題であることを認識してもらってから、次のアクションを考えてもらえるきっかけの一助に」という狙いから、上記のような資料になりました。僕が今まで問

    「SIerでのキャリアパスを考える」というイベントに登壇しました - GoTheDistance
  • VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0

    2013/2/14に目黒雅叙園で行われたデブサミ2013 【14-E-7】[TED] Technology Enterprise Developmentのセッションの資料です。 #devsumi #devsumiE Developers Summit 2013 Blog 「Developers Summit 2013に登壇しました。Ricoh UCS for iPad でみる エンタープライズ アジャイル開発」 http://numeha.hatenablog.com/entry/2013/02/16/130449

    VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0
  • Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている

    先日、経済産業省向けの仕事をしている知り合いと事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月30万円というケースもあるという。 こんな話を聞くと当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日で一人月30万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ

  • 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態

    今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩氏の提案についても掲載したいと思います。 以下からは萩氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記(注:記事の元になったFacebookへの書き込み)を書いたのは、二度とこのような案件が出ないよう質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 質的問題を提起したつもりですが、しかし当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何

    特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
  • 2012年に開発者が学ぶべき10のスキル

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ここ数年、ソフトウェア開発の世界は比較的穏やかだった。しかし、HTML5が地歩を固め、Windows 8がWindowsの開発シーンに大きな変化を迫っている今では、ジェットコースターの日々が戻り、スピードはますます上がってきている。もし最先端に居続けたいのなら、少なくともこの記事で挙げる10のソフトウェア開発スキルを身につけることを検討すべきだ。 1.モバイル開発 モバイル開発を学ぶのに時間を割く価値などないと考えているのなら、考え直した方がいい。2011年のAndroid携帯の世界出荷台数は、ほとんどPCの販売台数と同じだ。他の有名なモバイルデバイス(iPhoneiPad、そして「瀕死状態」のRIMデバイス)を加えれば、販売台数で見

    2012年に開発者が学ぶべき10のスキル
  • 開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは? - 達人プログラマーを目指して

    皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、年もどうぞよろしくお願いいたします。 さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。 グルーポンのおせち事件を受けてSI業界が当に教訓とすべきこと - 達人プログラマーを目指して この記事では、一般にSIerによって開発される日のシステムはあの事件おせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて 最近はOSSやクラウドなどの影響で社内システムもどんど

    開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは? - 達人プログラマーを目指して
  • システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道

    どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ

    システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
  • ソースコードの品質向上のための効果的で効率的なコードレビュー

    This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

    ソースコードの品質向上のための効果的で効率的なコードレビュー
  • Ruby開発の新メンバーは14歳の中学生! - @IT

    2011/04/14 オープンソースのプログラミング言語「Ruby」の開発コミュニティで、いま注目されている人がいる。福森匠大(Shota Fukumori、sora_h)さん、14歳だ。国籍、性別、年齢などは無関係というオープンソースの世界だが、これほど年若い参加者が「コミッタ」と呼ばれる開発のコアメンバーに迎え入れられることは珍しい。Ruby開発に加わった時点では中学2年生。「最年少記録」を塗り替えた。 欧米を中心にビジネスの世界でも迎え入れられつつあり、先日、JIS規格化もされたRuby言語。そのRubyの生みの親で、現在も開発をリードしているまつもとゆきひろさんに島根県から動画チャットで加わってもらい、福森さんに話を聞いた。 無料海外ドメインも使う「デジタルネイティブ世代」 記者への挨拶もそこそこに、最新のAndroid端末とMacBook AirをWiFiルータでネットに接続する

  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

  • InfoQ: より良いユニットテストためのガイドライン

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    InfoQ: より良いユニットテストためのガイドライン
  • あなたの履歴書を向こう5年間戦えるものにするために--今後必要な開発者スキル10選 - builder by ZDNet Japan

    最近の経済の変化から、現在多くの開発者が短期的な仕事を探している。同時に、スキルを習得するために時間とエネルギーを投入するのであれば、そこから確実に最大の収入を生むことが重要だ。ここで紹介する10のスキルのリストは、あなたの履歴書を向こう5年間戦えるものにするために、今すぐ学ぶべきものだ。このリストはとても網羅的とは言えないし、カバーし切れていない業界の分野も非常に大きい(例えば、メインフレームの開発者はカバーされていない)。とはいえ、平均的な主流の開発に対しては、少なくともこれらのスキルの7つを学んでいれば間違いはないだろう。就職の面接で説得力を持って話せるというだけでなく、これらは実際に仕事でも役に立つ。 1: 「ビッグスリー」の1つを学ぶ(.NETJavaPHP) 開発業界に(レッドモンドに隕石が落ちるというのに匹敵するような)劇的な変化が起きない限り、ほとんどの開発者は少なくと

  • 1