NHK紅白に"弾幕"流した男 小林幸子"ラスボス"舞台裏 (1/4)
小林幸子さんが、インターネットとともに紅白に戻ってきた。 昨年の第66回NHK紅白歌合戦、ニコニコで“ラスボス”と慕われる小林幸子さんの紅白特別企画出演。黒うさPのボカロ曲「千本桜」を歌いはじめてしばらくすると、巨大なステージ衣装にニコニコのコメントが流れはじめた。 ツイッターのタイムラインにも、「弾幕」「コメント」といった字面が躍った。歌が終わりに近づいたとき、テレビ画面全体がコメントで覆われると「おおおおおおおお」「すげえ」「まじかよ」とツイッターは一層の盛りあがりを見せた。 じつに4年ぶりの紅白出場だ。ネットにも活躍の場を広げ、若者たちとともに歩んできた小林幸子さんにとって、その結実ともいえる舞台となった。 失敗の許されない生放送、ラスボスを支えたのはドワンゴの技術部隊だ。 ニコニコ生放送のコメントをリアルタイムで紅白歌合戦に流す。一世一代のプロジェクトに挑んだマルチデバイス開発部
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
日本のIT業界に対するニュージーランド人エンジニアの反応｜NZ MoyaSystem
何度もブログで書いている通り、筆者がニュージーランドでの就職を目指している理由の一つは、以前勤めていたIT企業の文化にほとほと愛想が尽きたからです。 筆者は5年半、某メーカー系SIerでSEをしていました。まぁ大変な環境の中がんばってがんばって、ポッキリ折れちゃったんですね。 その時代の話をニュージーランドのIT業界の人にもお話することが時々ありまして、その反応がなかなか興味深いんです。今日はそんなエピソードを2つほど紹介したいと思います。 社内にシニアプログラマがいない？ 筆者が以前務めていたSIerでは、一般の例にもれず、プログラミングは協力会社さんに発注するのが一般的でした。社員がプログラミングをするのは入社後1〜2年だけで、その後は業務分析やマネジメント業務に従事することになります。ということで社内にはプログラマとしてのキャリアパスが無いに等しかったんですね。 という話を、某企業の
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
技術的負い目の記事がすごい - プログラマの思索
技術的負い目の記事がすごいのでリンクしておく。 【元ネタ】 16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。 そう簡単にリファクタリングしにくい。 そんな中で色んな対応をされている。 以下、自分が今後参考にしたいためにメモ。 【1】JDKが古い。 古いJDKはセキュリティホールもあるだろうから危険。 性能要件も低いだろう。 →JDK6からJDK8へバージョンアップ。 Gradleでビルド環境を作る。 ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。 【2】コード重複率も多く、デッドプログラムも多い。 長年運用したシステムは、デッドプログラムが多い。 でも、リスクがあるから、デッドプログラムをうかつに消去で
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
ユニットテストを書こう！ - Qiita
ソフトウェアエンジニアにとって、ユニットテストは重要です。僕はなるべくユニットテストを書くようにしており、ソフトウェアエンジニアはもっとユニットテストを書くべきだ、と考えています。ここで言及している「ユニットテスト」は、単なる「テストコードによる自動化」全体を指すのではなく、「テストから見えてくるグーグルのソフトウェア開発」で登場した用語である「Sテスト」を指します。 「テストから見えてくるグーグルのソフトウェア開発」では、テストコードが対象とするプロダクションコード(製品コード)の規模、S、M、Lとサイズごとに分類しています。 「Sテスト」とは、テスト対象のクラスのみを対象にしたテストを行うことを目的としています。テスト対象以外のクラスの処理は、積極的にモックを多用することで、テスト対象のクラスの振る舞いを確認します。 Sテストは主に品質向上に寄与すると「テストから見えてくるグーグルのソ
ガラパゴス化する日本の開発環境
とある日本企業との仕事で衝撃を受けたことを前回のエントリーで書いたのだが、より驚いたのが、それに対していただいたコメントやはてぶのほとんどが別に驚きもしない、うちもおなじ、というものだった。 ・いや、おそらく日本では普通だと思います。 ・そもそも人事部が採用する時に、技術スキルの高い人は取ろうとしませんし、ユニットテストのような基礎知識さえも全く知らない人が大半を占めます。 ・見直すための工数は悪、辻褄合わせるのが正義。 ・以前、某ERPパッケージの下請けで働いていましたが、テストを手動でやり続けるのに嫌気がさして、辞めました。あれは鬱になる...。 ・日本では専門家を軽視して、「ビジネスゴールを最優先して考える俺は偉い。技術馬鹿、専門馬鹿とは違う」っていうタイプの人材が評価される組織が結構多いのですよね。 ・あるあるすぎて、笑えない。 ・請負的な開発はこういった傾向が強いと思う。残念なが
中島聡氏が語る、世界で戦えるプロダクトリーダーを生む4つの条件【キャリアごはんvol.1レポ】 - エンジニアtype | 転職type
エンジニア同士が交流し、ごはんと悩みをシェアしながら 仕事人生の次の一手を探るためのワークショップ型イベント「キャリアごはん」のイベント情報やイベントレポートを紹介します 日々の仕事に追われて普段はなかなか考える機会のない「ひとつ上のキャリア」について、ごはんを食べるように自然に考えてもらいたい——。そんな想いを込め、エンジニアtypeと「今よりもっと満足できる仕事」との出会いを応援する姉妹サイト『@type』は共同で、新たにワークショップ型イベント『キャリアごはん』を立ち上げた。 第1回は9月29日、東京・青山にある『Royal Garden Cafe青山』で開催し、約60人のエンジニアが参加する形となった。テーマは、【Web・アプリサービス「次のデファクト」を生む現場リーダーになるには？】。MicrosoftでWindows 95/98開発のチーフアーキテクトを務めた中島聡氏と、国内企
要求分析と安全設計との関係（機能安全の致命的な欠陥）
日本の組込み系のソフトウェアエンジニアに担当製品に対するユーザー要求は何かを聞くとすぐさま答えられないことが多い。 顧客の要求に基づき日々ソフトウェアを開発しているIT系のソフトウェア技術者には驚きかもしれないが、事実そうなのだ。 なぜ、組込み系のソフトウェアエンジニアは自分の製品のユーザー要求を答えられないのか。それは、過去の製品のソフトウェアを追加、修正しながら新しい製品を作っているから、大元のユーザー要求を把握していなくとも、製品開発が出来てしまうからだ。 継承するソフトウェアの中に基本機能、基本性能がすでに入っているから、付加機能を付け足すぶんには元の要求を知らなくても作業はできるのだ。 さながら、老舗旅館の旧館、新館、別館、アネックスといったようなもので、結果、継ぎ足しで成り立っている迷路のような構造になることもしばしばだ。 継ぎ足し、修正ばかりやっているソフト技術者はユーザー要
ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2
SESSAMEで6月7日に開催するソフトウェア安全分析・設計セミナの資料を作っているところだ。 4月17日に募集要項を公開してから2日間で事務局宛に11名の応募があったようだ。（定員は30名なので参加を検討されている方は早めに申し込んで欲しい） 東京近郊以外の遠方から申し込んでいただいた方も半分くらいおられるので、その方達の期待に添う内容にしたいと思っている。 セミナで使うスライドはまだまだこれから作成、ブラッシュアップしていくので、参加を希望されている方達の業務ドメインを眺めながらそれぞれの実務でイメージが湧くような事例を多く紹介しようと思っている。 なお、このブログで ISO 26262 の特集記事を書いていることもあって、現在のところ自動車系のドメインの方の申し込みが多い。（自動車ドメインに特化した内容ではないので、他のドメインの方も来て欲しい） この記事では、『ソフトウェア安全分析
[SECメルマガ]2015.6.30_第108号：IPA 独立行政法人 情報処理推進機構
SECウェブサイトに利用登録され、メール配信サービスをお申し込みいただいた方へ お送りしております。※配信解除の方法については、文末をご覧ください ┏ SECメルマガ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ ☆ 第108号 2015.6.30 ☆ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ 「ETWest2015」の出展と「SEC特別セミナー」の開催が、無事に終了しました。会場 へお越しいただいた方に、改めて御礼申し上げます。また、ご参加されていない方 にも、SEC journalやメルマガなどで、内容をご紹介していきます。ご期待ください。 ―――――――――――――――――――――――――――――――――――――― INDEX 【1】コラム 【2】トピックス 【3】セミナー開催のお知らせ 【4】直近のソフトウェア高信頼化関連
やさしい機能仕様 パート4: ヒント - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/15 さて、私たちはなぜ仕様書が必要なのか、仕様書の中身は何か、そして誰がそれを書くべきかについて話してきた。このシリーズの最後のパートでは、良い仕様書を書くためのアドバイスをお話ししよう。 仕様書を実際に書いているチームから聞く最大の不平は、「誰も読まない」ということだ。誰も仕様書を読まない場合、それを書いている人たちはひがみっぽくなる。エンジニアが4インチの厚さの仕様書の山を使ってキュービクルを拡張している昔のディルバートの漫画みたいなものだ。典型的な官僚的大企業では、みんな何ヶ月もかけて退屈な仕様書を書いている。仕様書が出来上がると、それは棚に収められ、再び取り下ろされることはなく、製品は仕様書に書かれていることとは無関係にスクラッチから実装される。それは誰も仕様書を読まないから
やさしい機能仕様 パート2: 仕様書とはどんなものか? - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/3 (パート1はもう読んだ? 読んでなければ、ここにある。) このアーティクル･シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。 あなたが製品を隅から隅までデザインするとき、最
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「コードを書かなくなったら一人前」、そんな業界構造を変えたい
「製品開発におけるソフトウェアの品質保証」と題してプレゼンテーションを実施させて頂きました
TechCrunch | Startup and Technology News
捨てて開発できるチームづくり
http://local.joelonsoftware.com/wiki/%E3%82%84%E3%81%95%E3%81%97%E3%81%84%E6%A9%9F%E8%83%BD%E4%BB%95%E6%A7%98_%E3%83%91%E3%83%BC%E3%83%883:_%E3%81%A0%E3%81%91%E3%81%A9%EF%BD%A5%EF%BD%A5%EF%BD%A5%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6%E6%9B%B8%E3%81
http://local.joelonsoftware.com/wiki/%E3%82%84%E3%81%95%E3%81%97%E3%81%84%E6%A9%9F%E8%83%BD%E4%BB%95%E6%A7%98_%E3%83%91%E3%83%BC%E3%83%881:_%E3%81%AA%E3%81%9C%E3%82%8F%E3%81%96%E3%82%8F%E3%81%96%E6%9B%B8%E3%81%8F%E5%BF%85%E8%A6%81%E3%81%8C%E3%81%82%E3%82