はへん 破片プログラマー 大きなシステムの改修、 巨大に積み上がったプログラムの上での実装、 難度の高い仕事、 ただし破片 巨大な破片 画面を０から 二年、三年、五年と経験を積み、 開発スキルを身に付けたディベロッパー、 だがしかし、 ０から画面を作ってみると... ... あれ!? できない。 画面を０から作ったことがほとんどない。 あったとしても、隣の画面の真似ごとをしてただけ。 考えて０から作ったことがない レールのないところ歩いたことがない。 クラスやメソッド クラスを作る。 どうやって？どういう単位で？ 決められた中でしか作ったことがない。 その決めがないと何もアイディアが浮かばない。 「どこに何を実装するか？」って、 白いキャンパスの上で考えたことがあるかい？ ... メソッドを作る。 どうやって？どういう名前で？ どういう引数と戻り値で？ メソッドの修正はたくさんしてきたが、

先日、Twitterのタイムラインにこんなツイートが流れてきました。 【 #通訳ボランティア 】 英語コミュニケーション能力を発揮して、活躍してみませんか？#TOEIC #ラグビー #ボランティア 秩父宮みなとラグビーまつり2018 ▼詳細はこちら— TOEIC (@TOEIC_japan) 2018年4月27日 http://www.iibc-global.org/iibc/activity/volunteer/rugby.html 詳細はリンク先にあたっていただくとして、概略だけ記すと「２日間で、拘束時間は合計12時間。10名募集。イベントTシャツとイベントタオル、それに全日程合計で2000円の交通費を支給」とのこと。よくあるタイプのボランティア募集広告ですが、これは地域振興も兼ねてはいるけど「スーパーラグビー」というプロリーグのイベントですよね。それならきちんと予算を組んで、通訳者に

鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ

Twitterでこういうことを書いたら、そこそこ反応があった。 今のご時世、技術難易度が並ぐらい（一人でWebシステムが構築できる程度）で、2‐3人月ぐらいの小さなシステムを一人でヒアリング～実装～運用引き渡しができて、説明責任ちゃんと果たせれば、人月単価換算で80万円ぐらいは一杯転がってる（常にあるとは言ってない）し、その他要因で単価はもっと上がる— てるろー (@terurou) 2018年4月17日 意図通りには伝わらないだろうなぁと思いつつ、所詮Twitterだしなーと思いぶん投げたんだけど、想定してた範疇の誤解が広まってきたので、一応補足する。 「人月単価で80万円ぐらいの仕事」の難易度 ちゃんと書いてないから伝わらなくて当然といえば当然なんだけど、行間をちゃんと補うと、 エンドユーザー直案件 技術難易度的には、いわゆるマスタメンテナンス機能に毛の生えた程度のもの 一覧/詳細/編

1988年静岡生まれ・静岡在住。平日は制作会社勤務、休日は大体浜名湖にいる。 ダイエット目的でマラソンに挑戦するが、練習後温泉に入り、美味しいものをたらふく食べるというサイクルを繰り返しているため、半年で10kg近く太る。 前の記事：緑色にライトアップされた掛川城がすごい存在感 今回、異例の「本番無しマイクテスト」に付き合ってくれた音響マンは、わたしの父である。 音響マン歴38年。楽器店、レコーディングスタジオ、リゾート施設などさまざまな場所で音響の経験を経て、23年前に独立。音響の会社を立ち上げた。 駆け出しの頃はアマチュアバンドや売り出し中の歌手のライブ音響を、現在はホテルで行われる披露宴などのパーティー、コンサートをはじめとした舞台、企業や地域が主催するイベントの音響を主に行っている。 具体的な数字があった方が読者の皆さんに伝わりやすいと思い、これまで行ったステージの回数を聞いたら「

今年で東大駒場の非常勤講師を辞め、1年間実施した英日翻訳ウィキペディアン養成セミナーは来年から本務校の武蔵大学に移すことになったのですが、この辞職とクラス移動の経緯について皆さん興味があるらしいので、学生に迷惑がかかるなどの差し支えが無い範囲で簡単に説明しようと思います。めちゃめちゃ長いので、イントロのあと3つの節に分かれています。 ・イントロ まず、私は2013年に留学を終えて日本に帰ってきてからずっと東大駒場で英語の非常勤をしており、最初の二年は英語一列、今年は実験的な科目としてウィキペディアン養成セミナーをやっていました。学部から博士の一年まで東大駒場に所属していたので、英語一列には院生の時からTAとして関わっていました。去年からは武蔵大学に専任講師として就職したので非常勤先は辞めても良かったのですが、図書館とデータベースが使えること(これは研究者にとっては大変大事で、給料なんかより

20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない

これは、「ドリコム Advent Calendar 2015 その2」の、8日目の記事になる。 7日目は、middlemanとGitHub Pagesでブログを5分で開設！ほか盛りだくさん！ | いくら寝ても眠たい だった。 私は、ドリコムでエンジニアをしている matsusaki (@misoobu) という者だ。 ここでは、最近考えることの多い、組織におけるエンジニアの情報共有と、そのあるべき姿について書く。 また、それに関連して、コードレビューや設計についても触れる。 内容は、エンジニア視点のものになる。 情報共有は、組織にとって極めて重要だが、簡単なことではない。 本記事が、再考するきっかけとなれば、幸いである。 情報共有とは 情報共有を失敗するとどうなるのか 様々な情報共有 プロジェクトの状況や方針 作業内容とその状況 プログラムの設計やコード レビューの目的 レビューをするとき

Is No More QA Idealist Practical and Something Tasty?Yasuharu Nishi

2015-06-24 ニトリのコードを見てニヨニヨする会 雑記 情報リンク集 ニヨニヨ はじめに ニトリのECサイトであるニトリネットがリニューアルに失敗して6日も経ってから復旧したということで、 （一部の）プログラマクラスタで騒ぎになっています。 僕の率直な感想は次のようなもの。 閉鎖状態の「ニトリネット」が6/23にサイト運営を再開、不具合の主因はCPU不足 | ネットショップ担当者フォーラム ともあれ関係者の皆さまお疲れ様でした。個人の責任問題などと短絡化することなく、粛々と原因解明と、できればぜひ知見の共有公開をお願いしたい。2015/06/23 13:40 プレスリリースでは、原因としてCPU不足を挙げています。 珍しい原因ですよね。あまり聞いたこと無いのでぜひその知見を知りたいものです。 しかし雲行き怪しく 早速、ニトリのトップページ見ている。すごい8000行の中にデバックコー

わたしはちょっと意地悪らしい。 例えば、あるテストケースを思いついたとする（しかもかなりの高確率でうまく動かなそうなやつ）。それをね、モノが出来上がって自分の目でちゃんと動くこと（気持ち的にはちゃんと動かないこと）を見届けるまで、プログラマに話さない。*1 とあるイベントのパネルディスカッションか何かで @m_seki から「それは意地悪だなー」と言われて、はじめてそれが意地悪なんだってことに気がつきました。そういうテストを思いついたらすぐに言ってよ！てことみたい。もしプログラマがそれを考慮しないで実装してしまったら確実にバグになるわけで、黙っていることは開発にとって何のメリットもない。 なぜ話さないのか。話せなかったのか。それなりに理由はあったんだけど、まあ、それはいいや。意地悪は良くない。それからは思いついた嫌なシチュエーションや心配事は、なるべく言うようにしてる。 ということは、わた

ｃonstexpr関数はコンパイル時処理。これはいい。実行時が霞んで見える。cpuの嬌声が聞こえてきそうだ

2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。

コミュニケーションが生まれるツイートまとめツール

世間一般では、SIerは非効率、プログラマのスキルが酷い、ガラパゴス化している等、評判が悪く袋叩きにあっているようです。実際にはグローバル水準で戦える高スキル者はいるし、特に某親会社の人達はみな頭の回転が速いし、志が高いです。 一方で私の5年そこそこの短い経験の中でも、世間の評判通り、開発現場の信じられないような体たらくっぷりをたくさん見てきました。すごく立派な看板の裏でのしょぼい設計実装、ミス等 etc... (私も人のことを言えないですが・・・) そこで、私の見える範囲の世界で、どうしてこのような現状なのか考えてみました。 (私の見える範囲なので、他社だと全く状況は違うだろうし、他者には違った世界が見えているかもしれません。) SIerの問題点1. 技術力向上のインセンティブが少ない 恐らく最大の原因はこれではないかと思います。要するに、必死に技術力を磨くインセンティブが乏しいのです。