全てのCOBOLエンジニアはだいたい糞である
この記事を読んだ。 http://anond.hatelabo.jp/20160619185731 元COBOLエンジニア、現Rubyエンジニアとして増田の記事がどうしても許せなかったので反応してみる。 この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。 汎用系の現場でもRubyの現場でも優秀な人はたくさんいたし。 今では信じられないほどの経験を当時（といっても2年前）はしていた。 改めて今、RubyというかRailsを始めてよかったなーと思う。 そこで僕が経験した糞だった現場をご紹介したい。 （もちろん業界特有ということもあると思うが） インデントは定規で計るいやー、これが一番ひどかったな。 まず静的デバッグ（机上デバッグ）といってコンペアファイル、ソースコード、コンパイルログをそれぞれ紙出しして提出用（クライアント）、リーダー、上司用の3部印刷する。 全てマーカーを塗っ
「読書すると、仕事ができるようになる」は本当なのか？
知人のT氏が、「部下が本を読まない」という悩みを吐露していた。 「いくら言っても、全く本を読まない。発表させたりすると、しぶしぶ目を通してくるんだけど、ほとんど頭に入ってないみたいだ。どうしたらいいのか……。部下の一人は「本で読むより、実際にやってみたほうが良くないですか？」と言うんだよね。」 T氏は溜息をついた。 友人のY氏が、それに応える。 「絶対に本を読まなきゃダメなんですか？」 「うーん、そう言われると絶対、ってわけじゃないけど、仕事できる人はかなりの割合で本を読んでるよね。」 「……多分、それ逆だと思います。」 「どういうこと？」 Y氏は少し間を置いてからT氏に言った。 「教育学の先生から聞いたんですけど、「本を読むから知識がついてできるようになる」のではなくて、実は「ある程度できるようなったから、本を読むようになる」らしいですよ。」 「……どういうこと？」 「要するに「本」って
Swiftのコードレビューの時に確認しているポイント24選 - Qiita
概要 「自信が無いエンジニアこそコードレビューをするべき」なんて偉そうな記事を書いてから 半年が過ぎた今日この頃、コードレビューやリリースを繰り返し、これはレビュー時に確認しておいた方が良いな、と思った項目をまとめます。 こういうポイントも見たほうがいい！などあれば是非コメントでご意見頂きたいです！ レビューポイントは自分の中で大まかに分けて以下の2つにあります。 クラッシュ、不具合系 リファクタリング系 この枠に沿って、ポイントをまとめていきたいと思います。 コードレビュー時に確認しているポイントまとめ クラッシュ、不具合系 外部からのAPIを使う時にレスポンス内容がおかしいときを考慮してハンドリング出来ているか？nilが許容出来ない作りになっていないか？ 配列操作で配列の操作外を指すようなコードはないか？ OSVersionの違いで落ちたり、画面が崩れるようなコードは無いか？ バックグ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
