Shows
The AI Show Live showcases the amazing work happening in AI at Microsoft. Developers learn what's new in AI in a short amount of time and are directed to assets helping them get started and on the road to success right away. Seth Juarez and friends work on cool projects and highlight what's new in Azure AI and Machine Learning. Microsoft Visual Studio Code is a free, powerful, lightweight code edi
技術的負い目の記事がすごい - プログラマの思索
技術的負い目の記事がすごいのでリンクしておく。 【元ネタ】 16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。 そう簡単にリファクタリングしにくい。 そんな中で色んな対応をされている。 以下、自分が今後参考にしたいためにメモ。 【1】JDKが古い。 古いJDKはセキュリティホールもあるだろうから危険。 性能要件も低いだろう。 →JDK6からJDK8へバージョンアップ。 Gradleでビルド環境を作る。 ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。 【2】コード重複率も多く、デッドプログラムも多い。 長年運用したシステムは、デッドプログラムが多い。 でも、リスクがあるから、デッドプログラムをうかつに消去で
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
開発途中で退職したエンジニアの責任 東京地判平27.3.26（平26ワ12971） - IT・システム判例メモ
ソーシャルゲームの開発中に退職した従業員らが，会社から開発頓挫の責任を追及された事例。 事案の概要 Xは，ソーシャルゲーム（本件ゲーム）の開発を目的として設立された会社である。Yらは，Xの設立前から，Xのグループ会社の依頼を受け，本件ゲームの開発に関わり，Xが設立された後には，Xの従業員となって，本件ゲームの開発に従事した。 本件ゲームのリリースは，当初定められていた時期には間に合わず，延期された。 その後，Yらが，いずれも本件ゲームのリリース前に退職したところ，Xは，Yらが開発設計仕様書も作成せず，突然の退職によって本件ゲームの開発が頓挫して損害を被ったとして，主位的に不法行為に基づく損害賠償として，予備的に労働契約上の債務不履行に基づく損害賠償として，5400万円の賠償を求めた。 ここで取り上げる争点 Yらは，信義則上，あるいは労働契約上の義務として，開発設計仕様書を作成する義務があっ
受託開発の会社が自社サービスを1年運用してきた内容・結果と今後の課題 - ヴェルク - IT起業の記録
boardというサービスを正式リリースしてからちょうど1年が経ちました。 以前、「受託開発の会社が本格的にWebサービスを開発・運用してみてぶつかった課題（只今5ヶ月目）」という記事を書きましたが、その続きというか、現在の状況を書きたいと思います。 boardの開発の始まり boardは2年前の9月に開発を始めました。 その頃は起業して3年目の後半で、案件の管理や見積書・請求書作成などはExcelでやっており、案件数の増加とともに、Excel管理がだいぶしんどくなってきていました。 そこで、何か請求書作成系のクラウドサービスを使おうと思って探し始めたのですが、案件単位で受注するビジネスモデルにフィットするようなサービスがなく、また支払管理・売上管理・見込み管理など、自分が会社を経営する上で必要な部分まで欲しいレベルでカバーしているものがありませんでした。 ちょうど9月の連休があったので、自
プロジェクトマネージャへのお勧めの本 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ゲームAI -基礎編- 『知識表現と影響マップ』
みなさん、こんにちは! 突然ですが…皆さんには、ひいきにしている ゲームのキャラクターはいらっしゃいますでしょうか。 手ごわいボス敵や頼れるパートナー、愛嬌のある動きをするモンスター達は 一体どのような仕組みで動いているのでしょう？ 今回の記事ではそんなゲームの中のキャラクター達を 魅力的に動かす仕組み、AIについて御紹介したいと思います。 改めまして本記事を担当させて頂きます、Cygamesエンジニアの佐藤です。 これまでコンシューマ機でのゲームAI開発に携わり、 ゲームならではのキャラクター表現の楽しさを追いかけてきました。 このブログを通じて、皆さんのゲームのキャラクターを より表情豊かに魅力的なものにする方法について、皆さんと一緒に考えていければ幸いです。 今回はゲームのAIをデザインするにあたって重要となる、 「知識表現を定義する」というステップと、 知識表現の一つである影響マッ
1000万行のコードと向き合う3つのステップ――富士ゼロックスはリファクタリングにどう取り組んでいるのか
1000万行のコードと向き合う3つのステップ――富士ゼロックスはリファクタリングにどう取り組んでいるのか（1/2 ページ） 大企業では実施が難しいと思われるソフトウエアのリファクタリング。富士ゼロックスでは、どのように取り組んでいるのか。リファクタリングの実施を決断した理由、課題とその対応方針、成果、今後の展望などについて聞いた。 バグの有無ではなく保守性を品質管理の指標にすべき 1962年設立の富士ゼロックスは、主に複合機やオフィスプリンターなどに内蔵されるコントローラーソフトウエアの開発を行っている。コントローラーソフトウエアは、スキャナーで撮り込んだ画像の加工や印刷、ネットワーク経由の通信、セキュリティなどの各種機能を、操作パネルのユーザーインターフェースを介して制御しており、昨今の多機能なオフィス機器の要といえる。 一方で、多機能になったことでコードは大規模かつ複雑化の一途をたどっ
君のための本 -- ソフトウェア開発を一生の仕事としていいのか悩んでいる開発者に贈りたい1冊:2015年版 - 思っているよりもずっとずっと人生は短い。
（これは、『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』に寄稿した原稿の草稿を元に、XP本完全新訳版に合わせて加筆修正したものです。なんで完成稿ではなく草稿を元にしたかというと、草稿の方が長かったため短くまとめたものが完成稿になったからです。完成稿の方は『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』をどうぞ。） エクストリームプログラミング 作者:ベック,ケント,アンドレス,シンシア発売日: 2015/06/26メディア: 単行本 コンピュータ書を読むのが好きだ。だから「誰かに贈りたい本」と言われると、たくさんの本が思い浮かぶ。 たとえば君の問題が「プログラミングのスキル向上に思い悩んでいる」という話であれば、『Code Complete』辺りを勧めるだろう。プログラミング技術の本を10冊あげろと言われれば20冊くらいあげるかもしれない。 け
アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
何故僕はエンジニアとして対外発表をするのか | おそらくはそれさえも平凡な日々
僕は本来、人前に出て積極的に話そうとは思わないし、目立たずにおとなしく引きこもっていたいみたいな気持ちがある。潔癖な部分もあるので、プレゼンスばかり高くて技術力がないような中身が無い人間になりたくないし、そうなったら死ぬしか無い、みたいな気持ちもある。それなのに何故、ものすごく技術力があるわけではない自分が対外発表をするのか。 それは元はと言えば対外発表をするような側に行かないとエンジニアとして生き残れないのではないかという危機感があったからです。 Shibuya.pmの衝撃 初めて参加したShibuya.pmは#10だった。その頃の僕は一企業のよくある何でも屋の1人システム担当であり、開発のメインは前担当者から引き継いだレガシーASPだった。そしてつぶしの効く技術を習得したいと思いPerlを学び始めた頃だった。そしてPerlがそこそこ書けると手応えを感じ始めているところだった。 ところが
カブドットコム証券株式会社に対する行政処分について：金融庁
平成27年５月26日 金融庁 カブドットコム証券株式会社に対する行政処分について カブドットコム証券株式会社（以下「当社」という。）に対する証券取引等監視委員会による検査の結果、以下のとおり法令違反の事実が認められたとして、平成27年５月15日、行政処分を求める勧告が行われました。 ○システム管理が十分でない状況 (1)システム障害の管理が極めて不適切な状況 当社のシステム障害の管理の状況を検証したところ、 ア発生日時や事象の異なる複数のシステム障害が１件にまとめられ、実際に発生したシステム障害件数よりも大幅に少ない件数が執行役等に報告されており、執行役等もこれを容認していること イ顧客影響数について必要な確認が行われていないこと ウシステム障害の状況等の確認、原因究明、再発防止策等の検討及び執行役等への報告が、社内規程で定められた期限よりも大幅に遅れて行われていること など、システム障害
深刻化する日本のITエンジニア不足・・・解決方法としてオフショア開発が注目 : SIerブログ
http://news.mynavi.jp/articles/2015/05/22/seta-international_seminar/ いまIT業界は、深刻なITエンジニア不足の問題に直面している。みずほ銀行の基幹システム統合や 日本郵政のシステム開発といった大規模な案件に加え、マイナンバー制度の導入に伴う システム構築などによりITエンジニアの需要が急増。これらは、2015年〜2017年頃にかけて システムエンジニア不足がピークを迎えることから「2015年問題」や「2020年問題」として知られているが、 2020年に東京オリンピックの開催が決まったことでも、さらなる人材不足の加速が予想されている。 数万人規模におよぶ人材不足が懸念される中、企業はどのように対応していくべきなのか。 その解決方法として注目されているのがオフショア開発である。 オフショア開発先といえば以前は中国が中心だっ
休日に家でプログラムを書いていようがいるまいが、ヤバイ人はヤバイ
noon @n00nw0rks 仕事でしかプログラム書かない人は嫌だ、と思っていた時期が私にもありました。なお「仕事でしかプログラム書かないけど能力が高い」人に出会い考えが変わりました。仕事でしか書かないかどうかは能力に関係していることも多いが、してないこともあり、結局やる気も能力もないのが嫌というだけでした noon @n00nw0rks 逆に趣味でコード書いててもアレな人はアレで、以前「技術だけで飯食ってきたいっすわーマネジメントとかやりたくないっすわー偉くなりたくねぇ～」ってミサワしてた趣味でコード書く人が、同じ口で「俺は＜某技術分野＞については勉強しても分からないから仕事は回すな」とか言っててホゲーッてなった noon @n00nw0rks 社会人一年生のころにいた会社が本当にしゃれにならんくらい技術力が低くて、そこにいた人たちが全員仕事以外ではプログラム書かないどころかPCも触ら
技術的負債について考えた - 考えた。
技術的負債についての自分の考えをまとめます。 言いたいこと 最初から綺麗なコード・設計を書ける状態を目指せ。 そうもいかないものは天秤だが、勝手に背負うな。 技術的負債とは？ 技術的負債は事業リスクです。放置することによって事業が失速したり損害が発生したりするため、適切に取り扱う必要があります。 負債の種類と対応は、以下の三つに別けられると自分は考えています。 1. 新規で書く末端機能のクソコード・クソ設計 最初から綺麗なコード・設計を書けるを目指すべきですが、時間がかかるのであればスピード重視でよいでしょう。 「もっと良いように書けるべきだけど、どうすればよいか？」とコメントでも添えて、さっさとプルリを投げてしまうべきです。 末端機能で、あとで上に乗っかる物がないのであればコードの品質はそれほど問題ではありません。テストを整備しておけば、後でレベルが上がったときに綺麗にできるでしょう。
某社に見るシステム開発における社内政治の無駄さ加減について - novtan別館
業績は部署についてまわる 複数の部署が同じ目的の巨大システムに携わる 評価の基本は減点法である 業績をプラスにするよりマイナスにしないことが優先される 隣の島の人は同僚ではなく調整相手 文書のない調整結果は意味を持たない １分で済む会話より３往復かかるメールを選択する やったという証拠を残すためだけのレビューを実施する 指摘事項なしは疑われるのでフォントサイズにいちゃもんを付ける 監査はそれを見て満足する 予定と違う報告は許されないので報告の数字は捏造される できないから遅延するよりも中身が空でも枠だけで出来たことにするのが政治的に正しい どんなに正しくても政治的に間違っていると判断されたことは闇に葬られる 言ったもの負けで誰も言わないので全員が負ける（実は言ったら勝てることが多いが賭けを許容しない 常識で考えればこうするでしょということを決めるのに年収１０００万超の人の判子が１００個必要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
障害ヲ抱擁セヨ──大規模クラウドサービスをマイクロサービスアーキテクチャで作るNetflixが実践する障害注入テスト（FIT）とは何か | さくらのナレッジ
モダンWebシステム開発
エロサイトをマテリアルデザインで作り直した - 彼女からは、おいちゃんと呼ばれています
スポークのない車輪の「再発明」｜WIRED.jp