「例外処理」を含む日記 RSS

はてなキーワード: 例外処理とは

2018-03-12

anond:20180312005144

被ったときの影響が甚大だったら対応するし、大した事ないなら対応しなくていいでしょ。

まあ例外処理対応がとても簡単なら影響に関わらずやってもいいとは思うけどね。

2018-01-04

anond:20180104103117

コードを書く前に書くフローチャートは、だいたいこんな感じ。

前処理→中間処理→後処理
        ↓
       例外処理

たぶん、このくらいの粒度しか役に立たない。

2017-11-13

ダブスタ差別意識(例外処理)に基づくってのはまあわかるけど

だったらなおさらそんなの無くせるわけ無いやんってなるけど。

俺はやっぱりブラジルの知らない人より身近な友人のほうが大切だよ

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-08-22

大阪の人、あと外国人面倒くさい。

例外処理をしてくれっていう要求言葉に出すのはなんで?

慎み深さというものが、皆無−。

疲れるよな。

説明しきるまで、引き下がらないという面倒くささ、コスト

というか、聞けるオレ(ワイ・ワタシ)かしこーい、みたいなノリなんなの?

値引き交渉レジャーにすんな。  

日本人なら、日本の国から給料をもらい、日本健康保険制度を利用するなら、お役所仕事文句言うなー。

みなさん、そうしてますけど、なにか?

事務手続きには、時間がかかるものだし、何か?

文句ばかりを言う人は、日本から出てってくれたら、嬉しいですw

自分にもルール適応されているということが、自然と頭に入ってこないのかな?

大きな声で言われないと、理解出来ないのかな。

ちゃんと、義務果たして欲しいよなー。おつむりが足りないのかな?

2017-08-16

[] #33-4結婚はゴールじゃない!?

とりあえず、近場にいる色んな夫婦生活を密かに観察してみることにした。

けど、その夫婦の様子がちょっとおかしい。

「あれは……夫婦じゃなくなったっぽいね

離婚しちゃったのか」

捜索開始から、いきなり出鼻をくじかれた。

だがシロクロは意外にも喜んでいる。

「そうか、つまり離婚がゴールってことだ!」

自信満々にそう言ったシロクロを見ながら、俺たちはため息を吐いた。

私、女だけど、その結論おかしいと思う」

タオナケの言うとおりだ。その結論だと、離婚するために結婚していることになってしまう」

「シロクロには難しい話かもしれないけど、離婚ってのはしないに越したことはないものから。そんなものをゴールに据える位なら、最初から結婚なんてしなければいいって話になっちゃう」

「つまりシロクロの結論破綻しているってこと。それに結婚した後の生活もあるなら、離婚したってその後の生活もあるだろ。だから離婚はゴールじゃないよ」

「うーん、それもそうか」

ミミセンの話をシロクロが理解できたとは思えないが、納得はしているようだ。

「次だ! 次いってみよう!」

====

「あそこの人たち」

「いわゆるホームレスってやつだね」

「私、聞いたことがあるんだけど、ああいう人たちを“人生終わってる”とか言ってる人もいるらしいわ」

生きているのに人生終わってるって、よっぽどのことだ。

「そうか、つまりアレがゴールだ!」

「うーん、でも皆がみんなああいった風になるわけじゃないでしょ」

それもそうか。

一見すると人生終わっているように見えるが、あれでも生きていることには変わらない。

ホームレス例外処理できれば、ここで結論を出してしまってもよかったのになあ。

「……ひょっとして、ゴールなんてないんじゃないかな」

こういう時、割と核心をついたことを言うのがドッペルだ。

俺も何だかそんな気はしていた。

けど、それではあまりもつまらない。

私、女だけど、そんな頭カラッポ結論は嫌よ」

その気持ちはみんな同じだった。

けど、いつまでも見えそうで見えないゴールラインに、みんなヤキモキしていたんだ。

「そんなこと言っても、こんなに探しているのに、まるで見つからないじゃないか

「ゴールのないレースなんて走りたくない!」

「シロクロ、僕たちはレースの話なんてしていないよ」

だが、意外にも一理ある考えだ。

シロクロは何も考えずに言ったのかもしれないが。

ゴールもなしに人は走り続けられない。

ペース配分できないからな。

「うーん……」

この時の俺たちはさしずめランナーズハイで、いつまでも走れるような心地だった。

だがそれは、そう遠くないうちに息切れすることを意味していた。

それまでに、何とか結論を欲しい。

====

「なんか、あそこ騒ぎが大きくなってるな」

ホームレスの溜まり場で、やたらと人が集まっている場所があった。

ちょっとかめてくる」

変装が得意なドッペルに様子を見てもらう。

服をどこで用意していたかは知らないが、たちまち風景に馴染んだ見た目になる。

しばらくすると、俺たちが思っていた以上の成果報告をもって帰ってきた。

「……どうやらホームレスの人が誰か死んだらしい。原因は分からないけれども」

死。

それは、とても普遍的概念だ。

「となると、ゴールは死ぬってことか」

「うーん、確かにもう先はなさそうだよね」

「それとも天国とか地獄とかが実在するなら、死ぬこともゴールじゃないのかな」

「とは言っても、それは実在するか分からないしなあ。それに、もし輪廻転生かいうのがあったりしたら、ゴールどころかスタートに戻ってるよ」

「うーん……」

俺たちはゴールの見えない袋小路に入ってしまった。

走るのをやめて歩いている状態に近いかもしれない。

俺たちは走る体力も気力もなくなっていたんだ。

皆でしばらく唸っていると、ドッペルが何かに気づいたそぶりを見せる。

自信はなさそうで、恐る恐るその可能性を口にした。

「……なんだか“ゴール”って、候補含めてロクなものじゃないよね」

発想の転換に感動した一同は、まさに答えを見つけたといわんばかりに喜ぶ。

実際は何も導けていないんだけど。

「なるほど。そう考えると、結婚をゴール扱いされるのは確かに不服かもしれない」

私、女だけど、その考えに賛成するわ」

カンコン! ソウサイ!」

皆も迎合する。

「きっと、このまま探し続けても有るかどうかすら分からないし、あったとしてロクなものじゃないよ。そんなものを無理して暴いても、誰も得しない」

こうして、俺たちのゴール探しは、ゴールかどうかはともかく終着には向かったのである

(#33-5へ続く)

2017-05-22

http://anond.hatelabo.jp/20170522143218

簡単みえ事務作業が、実は例外処理連続で、とてもAIには任せられない難度の高い処理なんじゃ。

2016-12-24

最近摂取カロリー

おととい(木曜)

朝食

たぶん鍋の残り

昼食

弁当 750kcal

夕食

飲み会 計算

肉まん

ビール

アイス3個

飲み会を除いても確実に1600カロリーオーバー

しか飲み会と合わせて例外処理としたい

きのう(金曜)

ポテチ大袋 700kcal

ビール 1.5本 300kcal

アイス 1個(ハーゲンダッツ桃) 250kcal

いちおう1600kcal内か

飲み会から食事のペースがグダグダに崩れている

胃腸調子微妙に崩れて戻ってない感じがする

飲み会の前にLシステインの錠剤を飲んでおり、酔いはそこまでひどくなかったのだが

それでも翌日はずっと体調が微妙だった 動悸だったり

飲んだら酔うのだ、薬の過信はいけない

からはもう少し飲む量自体を控えよう

連休は体調を戻しつつがんばろう

2016-11-24

プログラマーの思うこと

プログラマーから製造業社内SE転職した。

VBAわかりますけど(キリッ)みたいな人が作ったマクロを直すのが苦痛すぎる。

なんでもエクセルでやろうとすんな。

マスタのデータエクセルに貼り付けたものをつかってVBA組むな。

変数はご丁寧に一番先頭で宣言祭りコントロール名前が連番、無意味な処理、データ件数を取得するためだけに同じSQLをCOUNTにして実行、無意味ループに、ifの4段ネストメソッド名が不適切(checkXXX)、スコープは全部Public、定数の概念無し(マジックナンバー多すぎ問題)、型変換の概念無し(文字列数字にぶっこむ)、例外処理なし、その他突っ込みどころ多数

オブジェクト指向なにそれおいしいの状態コードがどんどん増えていく。

てめぇのエクセルスキルはよーーーーくわかったから、これ以上クソコード増やさないでくれ

2016-11-05

PHP7で堅牢コードを書くとかいう風潮

いやまあ、これ読んだんすよ。

でさ、もうね、こいつ馬鹿なん?w ってゆう。

 

PHP7で堅牢コードを書く - 例外処理、表明プログラミング契約による設計 / PHP Conference 2016 // Speaker Deck
https://speakerdeck.com/twada/php-conference-2016

 

PHPみたいなレガシーゴミ言語にしがみついて、

必死に型とかEnumとか再発明って・・・

草すぎてコーラが無くなってしまうんだw

 

せめてさあ、Javaでも使えば?

いやっつーかホントPHPでここまで涙ぐましい努力しても、

劣化Javaしかないのが悲しいよね。

 

ペチプァっ~って馬鹿しかおらんのか?

こういうゴミ屑が勘違いして、

とか喧伝して糞案件量産してると思うと、反吐が出るね。

PHPと一緒にさっさと死んでほしい。

おまえもそう思うよな?

 

草プァ~~~w

2016-10-13

http://anond.hatelabo.jp/20161013150133

それこそ例外処理できる程度のことは受け入れるしかない。

祖父だって1/2は同姓だしな。

田中くんのお母さんの鈴木さんのお母さんの佐藤さん」とかなってくると、田中くんの保護者として鈴木さんとか佐藤さんが来るんだろ?

死ねって思うわ。

2016-02-10

育休から復職したんだけど仕事マジつらい

出産前は、イベント企画課みたいなところにいたんだけど、

そこは残業も土日出勤もあるところで、保育園の子供がいると無理ということで、

復職するとき事務課みたいなところに配属されることになった。 

 

 

事務仕事自体はそれなりに面白い

会社って縁の下でこういう仕事する人がいて成り立っているんだなーと、今まで知らなかった仕組みを知ることが出来たし、

学生の時に暇つぶし資格をとった簿記が今更ながら役に立ったのもうれしかった。

 

でも、正直つらい。

今の仕事は種類が多く、その上量も多い。手順は複雑で、1つでも飛ばしたり順番を間違えたりするとものすごく怒られる。

覚えても覚えても次から次へと新しい種類が出てくる。

少しでもミスを減らそうと、自分判断フローチャート作ってみたが、いちいち当てはめて判断していると人の3倍は時間がかかる。しかも、毎日のように新しい例外処理が出てきて、そのたびに新しく書き足したフローチャート無駄にどんどん長くなっていく。そしてなぜかミスは減らない。

残業がない課という話だったのに、定時では全く終わらず毎日残業していて、保育園の延長料金が家計を圧迫している。

  

  

前のイベント企画課の時は、ボーナス査定も上だったし、普通は偉くならないともらえない表彰状を最年少でもらったこともある。

決して自分無能というわけではないと思う。

ちなみに12月のボーナスは、今まで見たこともない低評価だった。つらい。おかげで育休中の家計赤字も補てんできず、子供学費ほとんど貯金できなかった。

普段の給料は半分が保育料で消えるので、ボーナスけが貯金のチャンスだったのに。つらい。

 

 

前の課に戻りたい。でも保育園は19時までしか延長できないし、土日はやってない。

夫は平日は終電帰りで土日もいないことが多い。実家は遠いため、やはり前の課に戻るのは無理だと思う。つらい。

2016-01-08

http://anond.hatelabo.jp/20160108154625

それはもう、本題から離れて行ってる気がするな。

ネットに慣れ親しんだ読者が持つであろうシンパシーと言う部分すらも捨てて、「不快になる単語」という括りにするのか。


でもなんだろ、ネットスラングが使われたと話題になって、結果論としてアニメ化までされたニャル子さんについて、後付の理由例外処理するなら、

この先、何を積んでも意味が無い気がするの、私だけですかね?

2015-07-25

正しさ

ドローンだの感電だの韓国中国だの個人情報漏洩だのより、交通事故で数千人が死に・数万人がカタワになってる事を対処すべきなのは絶対正義だが、それが問題視されず解決出来ない世の中ってホント愚かで愚民ばっかで見下したくなる。ゴミクズみたいな例外処理ばっか問題視すんのはなんなんだ。

2015-07-01

http://anond.hatelabo.jp/20150701154013

今まで、

例外処理コスト例外ユーザーによる損失

で、例外処理をしないで浮いたコスト分をメインユーザー還元という事かな。

それが、

例外処理コスト例外ユーザーによる損失

に変わった。

しか例外処理組み込み適正な価格にすることは=値上げになると。

結局はもとの想定が甘かったって事でしょう。

例えば酔っ払ってやらかす客への対応コストは折り込み済みでしょう?

居酒屋ならそういった例外処理普通想定するよね?

それともマナーの良い酔っ払いしかいない想定なの?

それらのコストに比べれば、飲まない客に別価格設定したり、

お引取り願う例外処理コストのほうが安いでしょ。

http://anond.hatelabo.jp/20150701152834

例外処理を怠ってそのぶんメインユーザーから多く取る設定にしているから、

例外処理をしない代わりにメインユーザにより良い条件を提供してるんだよ

http://anond.hatelabo.jp/20150701145903

しっかりメインのターゲットユーザーに対しては適切な設定をしつつ、

イレギュラーユーザーには例外処理

それが本来のあるべき姿だよね。

例外処理を怠ってそのぶんメインユーザーから多く取る設定にしているから、

セキュリティホールを突かれて破綻する。

2015-03-26

http://anond.hatelabo.jp/20150325232850

「軍だけども戦力じゃない」という例外処理は(実際過去にそういう解釈も可能であることが政府見解として言及されてはいるのだけども)

それ初耳なんだけど、具体的にいつ出されたどの見解のこと?

2015-03-25

http://anond.hatelabo.jp/20150325220129

陸海空軍が第二項で禁じる”戦力”の例示として挙げられている以上、「軍だけども戦力じゃない」という例外処理

(実際過去にそういう解釈も可能であることが政府見解として言及されてはいるのだけども)危ういよなぁと。

からこそ実際にはNGワード的に使用を避けてきたという歴史的積み重ねがあるのであって、その態度がいきなり変われば議論が巻き起こるのも(当たっているかは別として)仕方ないんじゃないの?

2015-01-19

仕様書に書いていない事を作らなかったら不具合

なぜライジングサンコーポレーションSEってのはプログラマーに対して、仕様書に書いていない事をやらせるのか?

仕様書に記載していなかった事を作りこんでいなかったら、不具合扱いされた。

いや、書いてある事を実現出来なかったらそれは不具合と認めるよ。

「書いていない」というと「常識だろ」と言われる。あんたらの製品常識かもしれないが、こっちには常識では無い。

ましてや、全てを底辺プログラマーのせいにして、なんとかという精神的追い詰め会議に呼び出すのはどういう事か???

それでも、「書いてくれ」と言い続けると、「全てを網羅出来ない」と開き直る精神がすごい。

なら「こちらも全てのエラー処理例外処理等を網羅出来ない」と言い返すのはタブーである。ここまで言うと、ライジングサンコーポレーションエライ人達はキレる。

全てをプログラマー責任押し付けるのはやめてくれないか。

品質向上プロジェクトとかあるようだが、プログラマーをいびる事で品質が上がると思っていたら大間違いだ。

君たちのその開き直りを直す方が先ではないかね?

2014-10-02

エンジニアズ=ハイ

大企業システムエンジニアは目の前の膨大なコードの前に立ち尽くし、いかに事故を起こさずに今回の客の要求だけを反映するか四苦八苦し、実装後はただ逃げ切る日を夢見る。俺の腐れ上司もちょこちょこっとシステム修正オフライン活躍し……ああつまり飲み会ゴルフ部長に媚びへつらい別の部署へ逃げ切っていった。

そうして俺の直上司は誰もいなくなり、一人か二人の学生上がりPGをメンバにもった俺が今度は修正をする番になる。


要求を読む。結構無茶な要求だが、敵はそれだけじゃない。コードが正ならコードを読めばいい。ただこの腐れ切ったコードが本当に正しいとは限らない。

俺は更新履歴の腐れ切ったワード仕様書を開く。誤字脱字のオンパレード例外処理云々といった赤字散見されつぎはぎだらけのゾンビーになっているのがわかる。



腐れ切ったコードと腐れ切った仕様書。この仕様書の記載をしたのはファイル更新日からすると二代前の部長だ。当時を思い出す。あの異常なスケジュール下でいいかげんな部長が変更仕様を仕込むとすれば、まずここの影響範囲の見込みを漏らすだろう。しかも高圧的な得意先だ。タフな交渉術を持たない部長のことだから得意先の負荷が高いインのテストパターンは申し入れしなかっただろう。ここも危ない。ああ、こっちもヤバそうだ。



そうやって前任者を想像しながら仕様書を読み込んでいくと、そこここに前任者のゴーストを読み取ることができる。俺はこいつをぶち殺すのが好きだ。まるで前任者自身をぶち殺せるかのような錯覚に陥る。



仕様書を生まれ変わらせる。そしてコードを生まれ変わらせる。腐れた部分をぶち殺す。このとき感覚を俺はエンジニアハイと呼んでるが、この業界、多かれ少なかれみんな似たような体験をしたことがあると思う。

学生のみなさんもぜひこの業界に来るといい。歓迎する。

2014-09-02

最近Web開発に感じる大きな谷(主にRails

10年くらいWeb開発業界にいて、ここ最近Railsアジャイルな高速開発的なものの周辺にいる。今は開発者マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。

あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニア面接やらに顔を出したりすることがあるのだが、ここ最近Web開発はますます主力級のゴリゴリ書けるエンジニア(いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る)と大したことのないエンジニアの差が開いてきたように思う。

主力級エンジニア

主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクト重要点とざっくりラフイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。

ソースコードフレームワークRESTfulの基本概念理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分フォローして修正することもできる。

仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい

大したことなエンジニア

一方、大したことなエンジニアは前述した流れが全くできない。

まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMSリッチUIなし)をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。

次に、品質が低い。できあがったと言われて念のためチェックすると、基本的CRUDレベルエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データseeds)の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。

パッと見に分からない部分もひどくて、ソース確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反JavaScriptエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能ソースコードコメントではTODOになっていたこともあった。

最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニア時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料ポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。

なぜ「大したことなエンジニア」がはびこるのか?

厄介なのは、こうした大したことなエンジニアも、Railsであればあちこちのチュートリアル記事書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。

彼らの作るサービスはまさに書籍チュートリアルサイトコピペ集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。

プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い(あえて「拙い」と書く)サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。

だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。

適切な例外処理担当者ミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニアなのだ

感じる「谷」

こうした主力級エンジニアと大したことなエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。

例えば、主力級エンジニアRailsだけでなくミドルウェアやprovisioning(chefとかansible)、最近ではdockerCIAWS新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん?」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。

そんなところに大したことなエンジニアはてブRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜(意訳)」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。

他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。

単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。

「大したことなエンジニア」の今後

こうした大したことなエンジニアは速度・品質難易度面で新規開発プロジェクトアサインするリスクが高いので、必然既存サイト運用メンテちょっとしたページデザイン文言修正)といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。

というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニア趣味ちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所(自作Webアプリ簡単に作れる啓蒙がなされている)がありそう。

ちょっと考えてみれば、文言修正デザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。

# もちろんそれでも保守契約責任分解点の関係外注するケースはあるだろうが、Rails採用するようなWebサービスは速度重視のことが多い

そんな中、この「大したことなエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステム運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。

せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。

早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか?

2014-07-23

http://anond.hatelabo.jp/20140723181259

いや、だから主語範囲は「男」だよ。範囲に疑いはない。

問題はどの程度まで例外処理として許されるか。

そこを曖昧にしたままじゃあ、論理的に間違いとは言えないだけで、何も主張してないに等しくね?

主語が大きい」って突っ込まれて、「例外があるのは当たり前だろ」って返すなら、「ああ例外があるんですね、結局何が言いたいの?」ってなるよ。

2014-07-18

http://anond.hatelabo.jp/20140718142219

例外処理できない証明ができないとダメ

いやいや、一般化することを正しいって主張するなら、例外はあらかじめ主張に織り込んどかないと。

からはてな民例外」なんて、勝ち負けでいったらその時点で負けてるよ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん