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

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

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

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

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

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

2014-05-30

考証1

議論していて、とても板がみずらいので。

こちらをお借りします。

そもそも、"ルールシステム特許になる"という彼の前提で

幾つか記憶を頼りに特許権を打ち砕いていこうと思います

269 :(´ー`)y─┛~~ ◆UxQ8uxJMok:2014/05/31(土) 20:12:01.17 発信元:123.225.138.170

>>266

> 全てこちらの論証通りとさせていただくだけですので、

> 私としては問題ございません。

オマエが真似れば殺しに行くだけだからこっちも問題ない。

という訳で、上記のとおり、

下記論証で解決いたしました。

スレ汚し、大変失礼いたしました。

01.連番召喚。場札を出す処理に連番の条件を要す処理。

⇒7並べ、大富豪にて類似システムあります

   連番召還ではないですが、「場札を出す処理に連番の条件を要す」に該当。

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

> 「場札を出す処理に連番の条件を要す」に該当。

↑場札が1枚の場合に「出す条件で連番」が満たされてないので反論として破綻。 ほぃ、論破完了ww

との反論がありましたが、

連番とは

複数の番号が連続していること。また、その番号。

とのことですので、1に対する2、2に対する1も連番となります

2つ以上の整数があれば成り立つ形式ですね。

場札が0の場合に関しては七並べではおきえない状態ですし、

こちらの特許も範囲外なので、例外処理です。


02.山札が尽きたら、コストを払わずプレイできる処理。

何をですか?

特許というからには「何のリソースコストとして用い」

「何のプレイを行う」のかによって異なると思いますが……。

ちなみに山札がつきた際に自動誘発する効果であれば、

コストを支払わない処理に該当するのかと思います

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

> 山札がつきた際に自動誘発する効果

↑まず、その「山札がつきた際に自動誘発する効果」とやらを具体的に提示できねば反論として破綻。 ほぃ、論破完了ww

こんな初歩的な質問が来るとは……侮っておりました。

基本的に、「デッキが0枚なら敗北する」というルールエフェクト

「山札が尽きたとき自動誘発する効果」なのですが、多分聞き入れられませんので具体例を。

Laboratory Maniac / 研究室偏執狂 (2)(青)

クリーチャー人間(Human) ウィザード(Wizard)

あなたライブラリーカードが無いときあなたカードを引く場合、代わりにあなたはこのゲームに勝利する。

2/2

万が一の保険

[部分編集]

刻の末裔 / エクステンションブースター

OPERATION

O-73 青 1-3-0 R

(自動A):自軍本国が0枚になっても、自軍プレイヤーは敗北しない。

(自動D):自軍本国が0枚になった場合、このカードゲームから取り除く。その場合、自軍本国を5回復する。

アンドリュー・バルトフェルド

蒼海の死闘 / エクステンションブースター2

CHARACTER(UNIT)

CH-S29 白 2-3-1 R

砂漠

【(自動A):自軍本国が0枚になっても、自軍プレイヤーは敗北しない】

【(自動D):ターン終了時に自軍本国が0枚である場合、そのターンの終了直後、自軍プレイヤーの新たなターンを開始する。新たなターンの終了時、自軍プレイヤーは敗北する】

MTGは若干異なりますが、ガンダムウォーカード勢は

「山札がつきた際に自動誘発する効果」とやらを具体的に提示してみました。

山札が尽きたら、コストを払わずプレイできる処理の一例です。

手札からじゃない:特許項目02に記載がないので割愛します。

破壊するって書いてある:それも含めての誘発効果です。「コストの支払い」は行われません。

04.数字1つで2つの反比例した表現戦闘力と、速度または類似の序列 など)。

戦闘力と速度が反比例している――だとっ!?

速度と戦闘力は反比例しない、凄い速度は威力に等しいので前提が崩壊しています

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

> 速度と戦闘力は反比例しない

↑当該ゲームシステムについての記述なので、お前は議論の対象を履き違えており反論として破綻。 ほぃ、論破完了ww

すごい!超時空会話が出来ました!

まず、その「当該ゲームシステムについての記述」とやらを具体的に提示できねば反論として破綻

05.自由に選んだ最初の手札で、ゲームを開始するシステム

手札の定義をしてください。

  まさか、全てのゲームに手札があると思っているわけではないですよね?

私ですらゲームをつくる際には「このゲームは~~を手札とします」という定義を行います

  ちなみに「最初に選んだ手持ち札」という前提であれば、金色のガッシュベルTCGの魔本でやっています

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

> 金色のガッシュベルTCGの魔本でやっています

↑手札とは任意に選択できる札であり、ガッシュベルTCGは選択できない仕様から山札に該当する。 ほぃ、論破完了ww

デッキの1枚目と2枚目が手札になる仕様というだけで……「任意に選択できる」のですが。

あれ? なにか私分かり難いこと言いました……?

一応、ポケットモンスタークメン列伝という、手札を全て任意に選べるものもありますから

そういう方向性を話した方がよかったのですかね?

06.山札から手札へ移動させず、原則として手札を場(場札)から追加するシステム。 【完了

  手札の定義をしてください。

  まさか、全てのゲームに手(ry

  ボードゲームとかでは、場にある3枚のカードから好きなのを手札に移していいよ、とか良くありますね。

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

◆UxQ8uxJMok :2014/05/30(金) 23:40:05.89 ID:mGswB6A1

の記載にて反論が認められませんでした。

当該項目に関しての検証完了させていただきます

08.標的を指定できない限定的行使権利行使権)と標的を指定する権利(標的指定権)等に、優先権を細分化したシステム。 【完了

   優先権は元々細分化されているので、そもそも論理が成り立っていないかと……。

  ttp://mtgwiki.com/wiki/%E5%84%AA%E5%85%88%E6%A8%A9

   ちなみに、この項目がTCGに限っていないので、TRPGウォーゲームなどでは乱戦処理などで

「標的を指定できない限定的行使権利」や遠距離攻撃の一方的に「標的を指定する権利」がありますね。

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

> この項目がTCGに限っていないので

パクリ兆候を感じた段階で、裏取りせず下記の警告文が送られ、そのトレーディング・カードゲーム制作者は~。

↑実物カードゲームhttp://ai.2ch.net/test/read.cgi/entrance2/1395426290/の~。 カードゲーム限定ね。 ほぃ、論破完了ww

すごい行間を読むと、確かにそうなっているみたいですね、難しいですが。

下の項目は論破(?)されてしまいましたが、

上記優先権に関しての記載にて反論が認められませんでした。

当該項目に関しての検証完了させていただきます



09.他者側に干渉する選択の直後に、強制的自分優先権が被干渉側に移動する処理   

遊技王の優先権の処理は必然的にこうなるようになってませんでしたか

   ttp://yugioh-wiki.net/index.php?%CD%A5%C0%E8%B8%A2=

カードを1枚使用すると、優先権が移行するので。

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

> ※カードを1枚使用すると、優先権が移行するので。

↑その1枚が「相手に干渉」しないのに移行するのだから当方の内容とは一致せず。 ほぃ、論破完了ww

それであれば、「特に本校に記載されている"特別な許諾行為"を行わずとも"当該行為と同様の処理は行うことができる"」ということですね。

特許権にあります有用発明」項目の独自性に含まれないため、特許権としての効力を失います

もし、「相手に干渉しない場合の行動は続けられる」という場合では他カードゲームよりも優位性はないので、

有用発明」項目の独自性に含まれないため、特許権としての効力を失います

この場合はどちらの選択肢を取られるのでしょうか……?

10.速度や類似の序列で、優先権プレイ権限など)や手番(ターン)を獲得する処理。

  その昔、実際のTCGとして出たアルテイルにはAgi(素早さ)の処理がありました。

どちらのターンであれAgi順に優先権が決定していたと思います

  うろ覚えですが、グリモアペインは例外だった気がします。

◆UxQ8uxJMok :2014/05/30(金) 23:39:14.66 ID:mGswB6A1

> アルテイルには~ Agi順に優先権

> 「クルセイド」には

↑それらは攻撃順序の判定であり、「優先権の移行判定」や「先攻/後攻の判定」ではない。 ほぃ、論破完了ww

攻撃順序の判定ではありません、上記に記載した通り「優先権」を得ます

「移動、待機、スキル使用、攻撃の判定を能動的に宣言できるタイミングである優先権」を得ることが出来るのです。

優先権を持っているプレイヤーが全ての行動ができる」とは限りませんので、覚えておくとよいですよ。

>>maitnagele ,sirua subilauin ertsepmC

2013-12-05

共働世帯の実態を書いただけで子供愛情が無いと断定されたでござる

ほんっと社畜って育児がどんなもんかってわかってないね

トイレのドアを開けたまま用をたす癖がついちゃってさ~。って言ってわかる?

やあ、当方東京在住30代後半同期入社職場結婚共働住居賃貸男女2児保育園在籍痔主歴15年です。

http://anond.hatelabo.jp/20131130161624

↑に書いたアレコレの一日のフロー例外処理は単なる事務処理みたいなもんです。

育児が辛いとも楽しいとも一切書いてないのに何故か子供を愛してないと書かれる不思議

コーラを飲んだらゲップが出るでしょ?それとコーラが美味いか関係あんのか?無いだろ!?

愛情かけたら子供の熱が治るの?糞まみれの衣類が綺麗になんの?って話ですわ。

まともに子育てに取り組んだ方々からは「それってふつーだよね」ってブコメを頂いていま

すが、そのとおりであほみたいに余裕が無く見える保育園育児だけど、あそこに書いたこと

って保育園に通わせてる親だったらほぼ皆、普通にこなしてることだから我々夫妻が特殊

いう事では無い。(妻のみが担当している家庭も多々あるが。)

当たり前の育児を読んだだけなのに「ドヤ顔で忙しいアピールうざい」みたいなコメントは最も

的外れで恥ずかいから明日から気をつけようね。

んで、もっと工夫して楽すれば?というご意見について書ききれなかった実践している(し

た)事を以下に述べる。

結婚直後

 産後育児の世話をあてにして妻実家の徒歩圏内に住む。

妊娠

 0歳時以外の保育園入園は倍率が非常に高く困難であることを調査。翌4月保育園入園の

 方向で決心。(公立保育園例外以外は4月以外入園出来ない。これ超重有。)

出産直後~離乳食

 夫も子供の面倒をみれるよう母乳ミルクの混合で栄養を与えることとする。

 これにより、夜泣き時や妻寝不足体調不良時に母乳が出ないから夫には手出しは出来な

 いという状況を回避

・住居

 諸事情で当初住まいを引っ越す際に賃貸メリットを活かし妻実家保育園中間地点へ

 移動。

・妻実家への依存

 あくまで予備としてのみ活用

 急な発熱時。どうしても行って欲しい通院等予備的に月に1・2度は妻母の出番となる。

食洗機

 当然使用。

保育園イベント

 面談等平日の保育園イベントは妻・夫いずれかで順番に出席。

保育園イベント

 正直我が園はどの家庭も忙しい。よって飲み会などは少なめと思われるが、開催された

 場合は常に夫妻同時出席。

・食事

 保育園で出されるバランス栄養食品に便り、正直手抜き気味。特に夫の作る料理コメ

 肉(OR魚)・作りおきの何か・味噌汁スープ)・果物。的なものが多い。

 コメは多めに炊飯冷凍米も作成

・第二子妊娠計画

 前回の反省を活かし4月~夏頃の出産を計画(赤子の時間を長時間育児休暇する為)。

 子作りを前年夏以後に実施

 計画通り夏前に出産。翌4月に0歳時で入園成功。(第一子がいると二人目の子供は同一保

 育園に入りやすいというのが重要。)

・夫・妻の飲み会イベント

 予定が計画され次第相手に通告。相手の日程が空いていれば機械的に参加可能となる。

で、こっちが重要な話なんだけど共働き育児ってマジおすすめ

何がいいって言うと、育児を大きなストレスに感じる事が無く楽しむ事が出来る。

(もちろん子供イラッとする事はしょっちゅうだがあくまで一時的な話。)

仕事育児オンオフがあるので気持ちの切り替えが出来る。

・一日中子供の世話をしなくていい(デメリットとして、初めてしゃべった。初めて歩い

 た等の全ては保育士が見ている。)ので煮詰まらない。

以下は夫妻で同じ会社に務めているという特殊メリット

通勤時等に会話出来ており、自分時間が足りないので、夜・休日などにパートナー

 話を効いて欲しい等、思うことは無く自分時間も少しは使える。

仕事トラブル発生時等に社内インフラメール等で即時相手に連絡・バトンタッチ出来る。

・相手が昼間なにやってるか気にならない。

もちろんこれらはパートナーとの関係性にや子供性格仕事ストレス度等様々な要因が

からむので一概にはいえないのは当たり前であるが、少なくとも我々夫妻は共働きしてい

る事で子供を愛していないという事は一欠片も無く、むしろストレス少なく子育てエンジョイ

していると自信を持って言える。

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