87歳運転の車が歩行者次々にはねる 母娘死亡 8人けが | NHKニュース
19日昼すぎ東京 池袋で87歳の高齢者が運転する車が自転車に乗る親子などを相次いではねたあと、ごみ収集車に衝突し、横断歩道を渡っていた歩行者を次々に巻き込みました。この事故で３歳の女の子と母親が死亡し、８人がけがをしました。現場にブレーキをかけた痕はなく警視庁は赤信号を無視して交差点に進入したとみて事故の状況を調べています。 警視庁によりますと、この事故で10人が病院に搬送され、このうち自転車で横断歩道を渡っていた近くに住む松永真菜さん（31）と、うしろの座席に座っていた娘の莉子さん（３）が死亡しました。 これまでの調べで、乗用車は最初にガードレールに接触する事故を起こし、70メートル先の横断歩道で自転車の男性１人をはね、その後、70メートルほど先にある横断歩道で死亡した親子をはねたということです。 さらに交差点を曲がろうとしたごみ収集車に衝突し、そのはずみで横断歩道を渡っていた歩行者４人
ジョエル・テスト
こんにちは。 タオソフトウエアの杉山です。 今回は炊飯について取り上げます！ 電気からガスへ 慣れると戻れない できるだけ大きな家電を買わずにすますため、 島へ移住の話【家電品 – 使わなくなった電子レンジ– 】 で触れた通り、もともと電子レンジで炊飯していました。これが水や米が変わっても使えそうな炊飯釜などを調べている中で、炊飯にガスを使うようになりました。 子どもの頃の実家のご飯も電気釜で、人生のほとんどは電気で炊飯されたご飯を食べてきました。ガスで炊飯するのは小学生の授業での経験ぐらいしかなかったですが、普段の生活で電気からガスへ変えてみたら意外と早く時間短縮になるので驚いています。 ガス代は少し上がりますが急上昇するようなことは無く、電気代が下がったので安上がりになりました。大島はプロパンガスのため、都市ガスだともっと安くなるかなと感じています。 昔のガス釜の炊飯器は壊れず美味しい
どうしてプログラマに・・・プログラムが書けないのか?
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
VB6からVB2008 への移行に関して
ＶＢ６（Visual Studio6.0)がWindows7や8で使えずいずれサポート打ち切り、最悪はそのＥＸＥも次期ＯＳでは動かなくなる恐れから止むをえずＶＢ２００８へ変換を試みていますが、余りにＶＢ２００８は利用者泣かせよくもこのような製品を世に出したなと言わざるを得ません。ＶＢ６で便利に使えていた機能をことごとく排除、オブジェクト指向と言う単に技術者の傲慢、自己顕示欲を示すだけの製品になっている。オブジェクト指向になってどこがどう便利になったのか複雑怪奇にしただけで便利さや機能の優れている点等どこにも見えない。ＶＢ６の便利な機能排除の主な物は以下の通り。 Inetコントロール、Winsockコントロールの排除、コントロールの配列機能排除、ポップアップメニュの左クリック排除、フォームのUnloadの排除等等 その他枚挙にいとまない。またこれを代わりの方法で実現する方法等本にも書いてない
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
「staticおじさん」はなぜ自信満々なのか
「staticおじさん」という言葉をご存じでしょうか。「static」というのは、Javaのstaticメソッドのことです。Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。 staticおじさんについては、わかりやすく解説したブログエントリが有名です（参考リンク）。実際のシステム開発の現場でstaticおじさんに苦しめられている様子をまとめたページもあります（参考リンク）。 なお、Javaのstaticメソッドを多用する人に限らず、古い感覚にとらわれて周囲に迷惑をま
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
ブラック企業社員は失業者とカウントすべき - ふろむだ＠分裂勘違い君劇場
池田信夫教授が「雇用は足りている」とおっしゃってます。 しかしながら、労働者が必要としているのは「まともな雇用」であって、「雇用ならなんでもいい」というわけではありません。 「まともな仕事が見つからないから、しかたなくブラック企業で働いている」という人がまだたくさんいるのに「雇用は足りている」とみなして政策判断すべきではないと思います。 ブラック企業でしかたなく働いている人のほとんどがホワイト企業に転職できるくらい人手不足になって初めて、「ほんとうの人手不足＝雇用は足りている」と言えます。 ようやくブラック企業が人を確保できずに赤字になり始めたぐらいじゃ、まだまだ本当の「人手不足」とは言えません。 ブラック企業のほとんどが人手不足倒産して焼け野原になってしまうくらい人手不足になってはじめて、本当の人手不足とみなすべきなのではないでしょうか。 こう考えると、「見かけ上のGDP」から「ブラック
Is Blockchain the most important IT invention of our age? | John Naughton
There are not many occasions when one can give an unqualified thumbs-up to something the government does, but this is one such occasion. Last week, Sir Mark Walport, the government’s chief scientific adviser, published a report with the forbidding title Distributed Ledger Technology: Beyond Block Chain. The report sets out the findings of an official study that explores how the aforementioned tech
xUTP Magazine - xUnitester Hotlinks: 第一回 和田卓人さん(下)
xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。 栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。 こちらは後編となります。前編はこちら 和田卓人（わだたくと） タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP（eXtreme Programming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めよう
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
開発会社におけるエンジニアスキル向上施策の過去と今｜TechRacho by BPS株式会社
morimorihoge@Webチーム部長です。ご無沙汰しています。ゴ魔乙はギルド戦が実装されてから拘束時間が多くなり、そろそろ見切りを付けようかとも思い始めた今日この頃です。とりあえずポケモンGOは始めました。 しばらくTechRachoに投稿できていなかったわけですが、別に遊んでいたわけではなく、むしろ開発会社としての本業の方で一杯一杯でなかなか記事を書く気合を充填できていませんでした。 今回は、最近社内で（というか主に僕のいるWebチームで）取り組んでいる社内エンジニアのスキルアップへの取り組みについて、これまでの経過と近況を書こうと思います。長いです。 ※今年に入ってから弊社は事業拡大を目指して採用活動を強化しており、現在進行形でメンバの増強を行っています。新しい人が入ってくる中で古くからの人もいるという当たり前のことではありますが、過去にこういう取り組みをしていたんだよという記録
Ｉｎｔｏ Ｔｏｍｏｒｒｏｗ コンパニオンより恨みを込めて。
本日の日記は、すごく暴走しています。 ＪＣに対する怒りでものすごい事になってますので、平和な話題をお望みの方は、読まないでください。 でも、ＪＣの会員には読んで欲しい。←ここに来る会員はいるのか…。 自分達がどう思われてるのか、じっくり読んで反省していただきたいと思います。 本人達に抗議したろーと思ってサイトに行ってみたんですが、メールがなくて怒りの持って行き場所がなかったので、ここで。 さて、私はパーティーコンパニオンという仕事が大好きです。 許されるなら、一生やって行きたいと思うくらい。 人に喜んでもらえるサービス業ができるというのは、私にとって天職やと思っています。 お客が常識を持った人であればね。 パーコンは天職と思っているこの私が、年に１、２回もうやめたいと真剣に悩むパーティーがあるんですよ。 むしろ、パーコンやめるって言うか、人生を投げ出したくなるパーティー。 それはＪＣ！日本
多分世界で最初のとんかつ評論家 元木一朗のブログ:ジョブ・キャリアの分割と、高度プロフェッショナル制度
先日、「ジョブなのか、キャリアなのか、それが問題だ」というエントリーの中で、ジョブとキャリアを明確に分けないから、日本人はホワイトカラー・イグゼンプションを理解できないと書いたのだが、ちょうど今日、こんな記事を見かけた。 ＜労働時間実態調査＞時間減らしたくても仕事が終わらず https://headlines.yahoo.co.jp/hl?a=20170722-00000086-mai-soci これは、ジョブとキャリアを分けて考えていないから出てくるひどい考え方の典型である。日本で言われている「高度プロフェッショナル」（高プロ）というのは、キャリア職の中で、さらに自分の裁量で業務量を調節できる立場の人間である。そして、その高プロ制度の導入に対して、ジョブ職の人間たちが反対を唱えているのである。おかげで、高プロの待遇も、その他のキャリアの待遇も、もちろんジョブの待遇も、ほとんど変わらない。
コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ #code #コード｜CodeIQ MAGAZINE
コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 （CodeIQ中の人） コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする
Android案件を見積もる場合に考えておくことリスト - Qiita
アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」 - TechとPoemeの間
TL; DR 「プログラマの三大美徳」はソフトウェアに向けるものであり，人に向けるものではない． 「HRT」は人に向けるものであり，ソフトウェアに向けるものではない． プログラマの三大美徳 プログラマの三大美徳というものがある．Perl を開発した Larry Wall が提唱したもので，「怠慢」「短気」「傲慢」からなる． 詳しくは上述のリンクにある各解説記事に譲るのだけど，例えば「怠慢」とは，「エンジニアとして手間を省くために最大限の努力をする気質」を指す．元の Larry Wall の記述では当たり前過ぎて省略されているのだけど，「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論，場合によっては前者が大事になるケースも有るのだけれど) ． 「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワー
ロードマップ指向とエコシステム指向 - アンカテ
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
