「デザインパターン」を含む日記 RSS

はてなキーワード: デザインパターンとは

2018-12-03

平成最後だしポンコツSE転職事情さら

平成最後だし、なんかい不況が来るかもわからない状況な気もするし、

今のうちに年収上げておきたいなんて考えている人もいるのかなと思い、

本当に普通な感じで埋もれているエンジニア転職した時の話をしようと思う。

現在私は同業界大手企業で働いている。転職結果としては年収も大きく上がったし、

職場環境も申し分ないので成功したと思っている。

 

スペック転職時)

 年齢:39歳

 

 <前職>

 中堅の独立系SI企業WEBSierもやってるような感じ)社員600名程度

 に所属していた。勤続は7年目

 

 <技術力>

 技術力はほんとに並の下程度。

 JavaとかPHPとかやっていて、PHPがメインだったかな。主にWEBサービスを作ったり、社内WEBシステム作ったりしてた。

 プログラミングの基礎はあるし、SQLやその他DB知識もそれなりにある。サーバー知識あんまりないし、

 Linuxコマンドは正直ちょっと苦手だし、AWSとか触ってないし、なんならApacheだってそんなに詳しくない。

 ググっていつも解決する。フルスタックエンジニア?なんだそれ?こちサーバーサイドエンジニアだ、文句あんのか?

 

 新しい技術言語は基礎があるので飲み込みは早い方だと思う。なので対応力はある方だ。Rubyでもpythonでもコード見れば読めるし、

 大抵のことは理解できると思う。でも業務では使ってない。JQureyもまぁ普通に使えるけどJSコードとかたぶん汚いと思う。

 

 色々と新しい技術をググって記事見たりして「わかった気になるタイプ」だと思う。36歳くらいでやっと「デザインパターン

 知らないとやばいんだ。勉強しないと!と焦って本だけ一応読んで「わかった気」になった。

 

 ここまで読めばわかると思うけどエンジニアとしてはだいぶ「ポンコツ」だ。

 でも仕事のためにやってるエンジニアとか結構こういう人が大半な気もするんだよね。

 立ち位置は開発リードとか設計とか上流も少しやってた。年齢のせいもあると思うけど、

 まぁうまく立ち回って仕事してた感じだと思う。コミュ力はそれなりにある方だと思う。

 もうエンジニアとかお前が名乗るなよとか言われそうだな。。。すまん。

  

転職活動の経緯

転職理由

 このまま、今のポジション仕事を続けてたら永遠に新しいこととか他の言語を使って業務をすることができそうになかったから。

 嘘だ、人間関係だ。ほとほと同僚、後輩、パートナーに愛想が尽きたからだ。それと上司やその上の部長にもだ。

 客先で顧客と一緒に仕事をしてたが顧客側の人はほんとにまともで良い人ばっかりだった。転職する時にそれだけ、ちょっと寂しくなったな。

 ポンコツながらプロジェクトでは納期を守り何とかやり抜いてきたが、全く評価されない現実もあり、それも嫌だった。あと、給料安い。

 表向きはいろんな理由があるだろうけど、転職する人の理由はきっとこれが現実だと思う。

 

概要

 転職を決意

 ↓

 とりあえずビズリーチよさそうねとか何も吟味せず登録

 ↓

 エン転職にも登録(以前使ったから)

 ↓

 DODAリクルート系は良い思い出が一切ないので登録してない。

 ↓

 ギークリーというところからビズリーチ経由で勧誘

 ↓

 一応そこの担当面談してギークリー利用

 ↓

 ビズリーチギークリーとエン転職転職活動

 ↓

 ビズリーチ経由でA社で外資強めの転職エージェントに会う。

 ↓

 ビズリーチ経由でB社で金融ITに強めの転職エージェントに会う

 ↓

 最終的にA社で3社応募して、2社内定をもらい転職した。

<詳細と雑感>

 転職しよう!と思ってからとりあず動けーーー!って感じで動いた感じです。

 総応募数は覚えてないけど30~50社くらいだったと思う。書類で超落ちる。年齢のせいも大きい。

 エン転職スカウト全然ダメだった。めぼしい企業がなかったし、年齢のせいか知らんけど、

 タクシーちゃんとかトラック運転とかそういうのも来てた。

 ギークリーから応募したのが一番多いと思うけど、とにかく手あたり次第に紹介してくる。

 よさそうな企業もあったけど、面接まで行ったのは4社程度ですべてお祈りだった。

 2次や最終までは行くが、いまいち紹介された企業自分志望動機を合わせる作業がどうにも苦手でうまく行かなかった。

 ギークリーはほんとに求人が多いから、たくさん見て選びたい人には向いてると思うけど、自分には向いてなかったな。

 他にもビズリーチ経由で4社くらい直接カジュアル面談があったけど、有名なY社とか、運輸系のY社のシステム会社とか、

 印刷系のD社の子会社とか、どれも最初カジュアル面談で、それ以後連絡なかったなぁ。

 カジュアルと言いながらガチ面接なこともあったな。

 

 そんな感じで行き詰って2か月。心機一転また別のところ!というのと、

 自分でもう一度ポンコツなりに職務経歴書を頑張ってブラッシュアップし、面接対策もして、改めてA社とB社とつながった。

 B社からの紹介はとても面白い会社だったし、一次面接もかなり好感触だったのだが、なぜかその後に論文筆記があり、

 書いて出したら、落ちた。どうやら思想が合わなかったらしい。

 A社から紹介されたのが、医療系のWEBサービスの会社と誰もが知ってる大手企業

 どうやら大手企業とは結構つながりのあるエージェント会社だったみたい。

 自分大手に行けるか半信半疑だったが、面接対策結構しっかりしてくれて助かった。

 同じ質問面接でされたので、うまく答えることができたと思うし、職務経歴書も一緒に見てくれた。

 そして、2か月でこの医療系の会社大手から内定を頂いた。転職活動は実質4か月くらい。

 どちらも良い会社だったので、本当に迷ったが、大手の方にした。

 断るのもエージェントがやってくれるのでこれも結構気持ちが楽だった。

 

<振り返って思うこと>

 ポンコツなりにアピールできるポイントがあれば、それをしっかりアピールするような職務経歴書を作ったり、

 私の場合は3回目の転職だったので、今までの経歴をきちんとよどみなくアピールできるような練習有効だった。

 転職活動初期は全然対策してないこともあって、やっぱり落ちたのかなと思う。

 だんだんエンジンがかかって、面接にも慣れていき、最終的に大物ゲットできた感じだ。

 そして、面接ではやっぱり自分はできる奴だ!ということをちゃんアピールした方がいいと思った。

 謙遜かいらないし、こういう職務なんですができますか?と言われても、普通に全然問題ないです。くらいに言ってもいいと思う。

 

 ハイスペックエンジニアかいやいや十分すごいですわ的なエンジニアは、自分活動して、普通に交渉もして、

 自分がより有利な環境を手に入れることができると思うけど、私のようなポンコツ普通にエージェント使って、

 普通に応募して、面接対策しっかりして、志望動機ちゃんと頑張ってたくさん考えて、ちゃんと喋る練習して、それで行けば結構いけると思う。

 落ちるのはやっぱり職務経歴書がまだちゃんと練れてないのと、面接練習や、志望動機が甘いんだと思う。そこを頑張れば良い環境転職できると思う。

 

 おススメのエージェントとかは特にいかな。自分に合ったもの自分転職活動しながら、見つけるのが良いと思う。

 1つ言うならエージェントを1つに絞らないことかな。忙しくなるけど、いろんな所と付き合って、自分に合うところを見つければいいと思う。

 そういう意味ではビズリーチは大小さまざまなエージェント会社があり、そこから連絡がバシバシ来るので登録しておくとよいかもしれないです。

 

<まとめ>

こんな感じだ。読み返すとあんまり参考にならないかもしれない。。。

私は前の会社全然評価されなかったが、今の大手に移ったら、普通に評価が上がって、給料もしっかり上がった。

環境次第で人の評価って全然変わるし、所詮評価する側のフィルターをかけた評価なんてやっぱり気にしなくていいんだと思った。

実際前職の部長退職の旨と転職先の話をした時に「子会社ですか?」とか言われたし、「いえ、本体です。」と答えたら「マジで?」という顔をしてた。

部長フィルターでは自分評価はそんな感じだったんだなと実感した。

ももちろん良いフィルターをかけて評価してもらっていると思うけど、自分にとってどっちが良いかは明白だし

その良いフィルターが本当になるようにもっと努力したいと思う。

 

今の市況ならほんとに転職すれば年収上がるくらいの状況だし、勤続3~5年以上で、

自分の現状に不満があるなら、いっちょやってみるのも良いかもしれません。

誰かの参考になれば幸いです。

2018-11-19

1ヶ月でJavaをマスターする学習カリキュラム

どうやったらプログラミング経験者を1ヶ月で一人前のJavaプログラマーにできるだろうか?

 

基礎

 

応用

 

これらを1ヶ月程度で詰め込むことは可能なのだろうか?

1ヶ月でJavaマスターした人がいたら、教材とか順番を教えてください。m(__)m

 

Railsエンジニア研修

はてなブックマークでバズってた宣伝を見ると、4ヶ月の研修Railsエンジニアを育成していた。

研修の成果を3行で

 

ざっくりスケジュール

4月
5月6月
7月

かなり余裕のあるカリキュラムで、OOPの基本を学ぶなら、(静的な型付けがないけど)Rubyはいいよね。

Java最初に覚えるべき知識が多過ぎて、初心者学習用途には向いてないと思う。

PythonRubyなど、グル言語LLプログラミングの基本を理解する。その後にJavaで肉付けする。という順番が良いと思う。

 

でも、いきなりJava現場に放り込まれたら、そうも言ってられないわけで、無理矢理でも1ヶ月でJavaマスターするしかない。

この無理ゲークリアするためには、教材と順番を工夫するしかないだろう。

どうだろ?

2018-10-28

singleton」に対応する、複数を示す英単語は?

一応その界隈じゃ multiton という単語が使われてるけど、これは通常語彙には存在しない。あくまでもデザインパターンにおける singleton からの生成だ。なんとなく決まりが悪いので singleton対応する英単語を教えて下さい。英語詳しい人。TOEIC900点以上で帰国子女はてなーの皆さん!いつも上から目線で偉そうなコメントをしてる皆さんこれくらい分かるでしょ?教えて下さい!

2018-10-23

増田プログラマー養成講座 その10 OOP参考書

前回はオブジェクト指向プログラミングOOP)の使いどころを学ぶために、MVCフレームワークを使ってみました。(ほんの触りだけ)

今回はOOP理解を助けるための参考書を探してみましょう。

 

OOP参考書

OOPに関する有名な本はたくさんありますAmazonレビュー評価が高い本は、定番の本が多いです。

だけど分厚い本は、ある程度プログラミングに慣れてから読んでみないと、最初意味チンプンカンプンだと思います

最初意味が分からなくても)なるべく早い時期に1回は読んでみた方が良いと思う本をピックアップしてみます

 

オブジェクト指向でなぜつくるのか 第2版

この本は、OOP概要、基礎知識コンパクトにまとめられています

今の自分知識の過不足をチェックできます

この本を1つの目安にして、今後の学習指針を立ててみて下さい。

 

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

https://www.shuwasystem.co.jp/products/7980html/4614.html

この本は、OOPも含むプログラム設計ノウハウ原則をまとめて紹介しています

カタログ的に、各テーマを広く浅く紹介してるだけなので、詳しい内容は個別に掘り下げる必要がありますが、それでも概要を知る上では役立ちます

今すぐ理解できなくても、「あー、そういえば、そういう話もあったな」と後で思い出せる程度に眺めておくだけでも十分だと思います

(第3章にある「UNIX哲学」は、初心者にとってプログラミングの良い指針になると思います。)

 

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

https://gihyo.jp/book/2016/978-4-7741-8361-9

この本は、上記2冊の内容を具体的な事例で説明しているような本です。

OOP解説本をいろいろ読んでみると、

などといった用語に出くわすと思います

これらの内容はそれぞれが1冊の本になるほどボリュームの多い内容ですが、本書ではそれらのエッセンスをうまくまとめていると思います

サンプルコードRuby説明されていますが、何らかのOOP言語を使ったことがあれば、Ruby文法を知らなくても、だいたい意味は分かると思います

 

プログラミング入門書を数冊読んだ程度の段階では、上記の本を読んでもいまいちピンと来なくて、意味理解できないと思われます

しかし、将来自分がぶち当たるであろう壁、課題を先取りしているつもりになって、「こんなことも考慮してるんだな!」と雰囲気だけでもつかんでもらえればいいんじゃないかと思います

 

プログラミングって難しいイメージがありますけど、習うより慣れろの精神で、とりあえず適当に触ってみるのがいいと思います

 

その他

PHPを使って、OOP基本的な仕組みを説明をしたので、PHP入門書を挙げるなら、とりあえずこの1冊。

自分にとっては分かりやす説明だと思うのですが、類書はたくさんあるので、実際に本屋で確かめてみましょう。

 

Java入門書文法の基礎を学んだら、次に読んでみたい本。

デザインパターン」という知識があると、他人が書いたプログラムを読むときに役立つと思います

(なんでこういう書き方をしてるんだろ?とか、定番の書き方=パターンがいくつかあるので。)

 

グチャグチャな汚いコードを綺麗にスッキリさせるノウハウがあります

リファクタリングに関する知識を学ぶと、プログラムの書き方が改善されて、後で自分メンテナンスするときに苦労が減ります

 

今の段階では、パッと思いついた本はこんなかんじだけど、他にも良い本はいっぱいあります

自分が分かりやすいと思う説明方法と、他人が分かりやすいと思う説明方法は、必ずしも一致してない場合が多々あります

図書館本屋で、実際に本の内容を確かめてみて、自分にとって一番分かりやすいと思える説明の本を探してみてください。

 

本のコストパフォーマンス

リファレンス文法辞書など)は、読む頻度が多ければ、買って損はしない=元は取れると思うので、自分への投資だと思って、必要な本は買うようにしましょう。

プログラミング専門学校かに行ったら、学費が何十万円もしますね?それを思えば本なら安いものです。)

 

プログラミング学習曲線

プログラミングに限らず、他の勉強でも同じだと思いますが、最初は知らないことの連続ですね?

プログラムサンプルコードを見ても、意味が分からなくて、中身が不明な「ブラックボックス」に見えると思います

でも、いったん意味が分かるようになると、霧が晴れたように、急激に視界が開けてきます

学習曲線で言えば、滑らかな右肩上がり(/)ではなく、ある時グイッと変わる階段状(_l ̄)の変化に近いと思います

なので、最初は分からないことが多く感じても、それが当たり前なので、あまり気にする必要はないです。

理解を早める補助として、上記のような参考書活用されてみて下さい。

 

まとめ

今回までで、手続言語構造プログラミングオブジェクト指向プログラミング)の基本を知りました。

次回は、問合型言語SQL)を学び、データベースを使いましょう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書 ←★今ここ★

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-09-27

DDDって

プログラム設計する上で、一番大事なことの1つが『物事をどううまく抽象化するか』だと思ってるからデザインパターンはまさにそれ)DDDって全然うまく行くイメージがないんだよな

2018-09-25

いつかの社内勉強会ネタに使えるかもしれないので記録。

ContainerPatternで"Ambassador Pattern"(Googleで直訳すると、大使紋章..めっちゃかっこいい)というのがある。

https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador

なにが大使やねんというと、サービスAがサービスBに接続するときサービスA'がサービスAの代わりにしてくれるかららしい。外交官的な。

接続にかかわるもろもろ、回線監視だとかリトライ処理だとか認証だとかそもそも接続する設定値だとかそういったものを代わりにやってくれるサービスを別途にもうけようぜという仕組みだそうだ。

その仕組みがはまる例として

・異なるプログラミング言語だとかフレームワークサービスを織り交ぜている

アプリ開発者が認証の仕組みまで意識して作りたくないよ

という時だそうだ。

ふむふむとうなづきつつ、アンチパターンの方で躓いた。

つのプログラミング言語しか使ってない場合メリットからクライアントに直接通信用のライブラリ入れろよというのは納得...したんだが、

Consider the possible impact of including generalized features in the proxy.

For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent.

一般的機能プロキシに含める影響を考慮してください。例えば、リトライ処理をするとき、全ての処理(注釈: アンバサダーリモートサービスに対する処理)が"冪等"でなければ安全ではないかもしれません。

冪等ってなに?え、リトライ処理でデメリットが生じることがあるの?(ログイン試行回数とか?)

有識者的にはあーっ知ってるよで終わる話(隣の技術者に聞いた感じ)なのかもしれないけどそもそもidempotentの訳を知らなかったので

ググると、"treasure data"の中の人ブログにたどり着いた。

リトライと冪等性のデザインパターン

これだよ!!これが俺が知りたかたことなんだ。ありがてぇありがてぇ。

接続しようとしている外部リモートサービスの話で合って、リトライする側のアンバサダーサービスが考える話ではないし、

接続しようとしているサービスに応じてアーキテクチャ設計が変わっちゃうと本末転倒感あるけど、

少なくとも考慮すべきポイントであることは了解だ。

...はぁ、勉強したー!!

2018-09-22

[]2018年9月21日金曜日増田

時間記事文字数文字数平均文字数中央値
008510358121.973
01559637175.283
0223197485.844
03123376281.387
0482076259.573
05418847.017.5
0616100262.644.5
07282941105.049.5
08505085101.742.5
09798225104.144
10999979100.849
11105764472.843
1210313260128.750
1399889489.858
145810724184.954.5
1597908193.656
161541312485.238
1777572174.334
1883587970.844
1971684396.453
2091891097.942
211221041685.437.5
221381249390.545
23678714130.158
1日1724176544102.449

頻出名詞 ()内の数字単語が含まれ記事

人(188), 自分(133), 話(93), 今(76), 意味(57), 仕事(57), 問題(55), 前(55), 女(55), 増田(54), 感じ(52), 人間(50), 好き(49), 日本(49), あと(44), 子供(43), 関係(42), 気(40), 社会(39), 普通(38), クレカ(38), 気持ち(37), 結婚(37), 男(37), 結局(36), 必要(36), 時間(36), 頭(35), 理由(35), ー(34), 場合(33), 会社(33), 相手(30), 一番(29), 最近(29), 金(29), 現金(28), しない(28), 無理(27), 他(27), 存在(27), 全く(27), 主張(26), 最初(26), 女性(26), じゃなくて(26), 自体(25), ネット(25), 馬鹿(25), 意見(25), ダメ(25), LGBT(24), 絶対(24), 嫌(24), 人生(23), 全部(23), 否定(23), 勉強(23), 政権(22), 目(22), 毎日(22), 年収(22), 正直(22), 内容(21), 世界(21), 別(21), 結果(21), 大学(21), 当たり前(21), オタク(21), 政治(21), 時代(21), 民主党政権(21), 親(21), 言葉(20), 手(20), いじめ(20), バカ(20), 出て(20), 人たち(20), 誰か(20), 世の中(20), 今日(19), 価値(19), 嫌い(19), 理解(18), 情報(18), 無視(18), 判断(18), 自民党(18), まとも(18), 仕方(18), 日本人(17), 全て(17), レベル(17), ただ(17), 確か(17), 家(17), 他人(17), いや(17), 表現(17), ゲーム(17), 事実(17)

頻出固有名詞 ()内の数字単語が含まれ記事

増田(54), 日本(49), クレカ(38), じゃなくて(26), LGBT(24), 民主党政権(21), 自民党(18), 東京(15), 元増田(14), 被害者(14), スマホ(14), 同性婚(13), 飲み会(13), ネトウヨ(12), twitter(12), 可能性(11), ワイ(11), なのか(10), いない(10), 安倍(10), アレ(10), 石破(9), アメリカ(9), 社会的(9), わからん(9), KKO(9), 10万(9), 障がい者(9), ゾーニング(8), ラノベ(8), 民主党(8), ツイッター(8), ブコメ(8), 個人的(8), 自民(8), w(7), 韓国(7), アベノミクス(7), ブクマカ(7), お気持ち(7), 社会人(7), なんの(7), PC(7), キモ(6), カツカレー(6), 鳩山(6), 工作員(6), 非モテ(6), OK(6), アプリ(6), リアル(6), 睡眠時間(6), ブクマ(6), 中国(6), ???(6), 基本的(6), 普通に(6), 何度(6), いいんじゃない(6), ありません(5), s(5), SNS(5), なんだろう(5), ja(5), 何回(5), ガチ(5), 毎日(5), hatena(5), 3日(5), 自分たち(5), 就活(5), ツイート(5), あなたに(5), 価値観(5), 昭和(5), マジで(5), Twitter(5), モリカケ(5), 笑(5), NG(5), やな(5), 2ch(5), はてな民(5), 30分(5), いいね(5), ポケモン(5), イケメン(5), 8時間(5), 6時(5), 性的嗜好(5), ニート(5), 経済的(5), …。(5), 生産性(5), 知らんけど(5), リア充(4), 自部(4), キモカネ(4), 1回(4), 支持率(4), YouTube(4), 脳内(4), 野田(4), 暗黒時代(4), DINKS(4), -1(4), 数年(4), 差別主義(4), ネトサポ(4), 日本国憲法(4), FX(4), BGM(4), いつまでも(4), どんだけ(4), 40分(4), 30歳(4), 1人(4), 無料クーポン(4), コレ(4), 日本社会(4), ブックマーク(4), ネット上(4), コミュ力(4), 娘(4), 大企業(4), 生活費(4), 分からん(4), 8時(4), 積極的(4), パワーエリート(4), 夫婦(4), ブログ(4), 涙(4), パヨク(4), な!(4), gt(4), 自己肯定感(4), 自衛隊(4), 海外ドラマ(4), 優先順位(4), 統計データ(4), ダメダメ(4), ジップロック(4), AI(4), はてサ(4), ヘテロ(4), 7時(4), 私たち(4), サイコパス(4), 性的志向(4), TPP(4), LINE(4), キモい(4), 一緒に(4), 消費税(4), である(4), blog(4), 正義(4), 表現の自由(4), 加害者(4), 50代(4), にも(4), 専業主婦(4), 10分(4), 1年(4), 性犯罪(4), 米(4), 発達障害(4)

投稿警察もどき日中に再投稿された本文の先頭20文字 ()内の数字投稿された回数

(3), しゃぶれよ (3), https://www.revive(2), これ、万が一全国ネットテレビに出て(2), デザインパターン全く身についてないな(2), 島﨑信長 (2), つまり生産性がない (2), 資金力の差だな。 でも、日本漫画や(2), 返信ありがとう中退すると大変そうだ(2), はい (2)

頻出トラックバック先(簡易)

会社社員がしょぼすぎる /20180921004242(14), ■出雲の阿国冥土土産自由の女神 /20180920162045(13), ■自分いじめてた人がお笑い芸人になってた /20180918012627(10), ■オタク生活を通して、人を学歴判断するようになった話 /20180921130154(10), ■政治に興味がない若者です /20180921225703(9), (タイトル不明) /20180921090508(9), ■コミックの目次って意味あんの /20180920223440(8), ■ /20180921202656(7), ■一番理解できないの /20180921162358(6), ■継承って結局いつ使うの? /20180921182403(6), ■性的消費 /20180921130159(6), ■あざとい語尾が鳥肌立つほど嫌い /20180919133727(6), ■いまのままではやはり同性婚を成立させるのは難しい /20180921120620(5), ■アベノミクス雇用が増えたのではなく、団塊の世代定年退職し始めたのと、改正高年齢者雇用安定法によって老人用の求人も出始めたからです /20180921214016(5), ■年収400万以下の男って存在してるの? /20180921210240(5), ■東京に住む人は早死にすると思うしカリカリしてるのも当然:2 /20180921093437(5), ■35歳なのにまだ夢を追ってる夫が嫌いになってきた /20180919003925(5), ■プライドのない奴が「俺にも」「私にも」と言ってくる /20180921132011(5), ■食材包丁トントントントン切るコツを教えて /20180920102434(5), ■東大の友人「受かったときに鼻で笑われたのに絶望した」 /20180920125124(5), ■30歳になってから出し切ったはずなのに小便が漏れるようになった /20180921191850(5), ■余計なお世話 /20180921015930(5)

増田合計ブックマーク数 ()内の数字は1日の増減

5635441(2053)

2018-08-15

生産性ゼロどころかマイナスな同僚

ほぼ愚痴です。

エンジニアなんだけど、ひどい同僚がいる。

酷い点を挙げればキリがない。当人が何も生み出さないだけならまだしも、他のメンバー生産性まで下げるので、非常に手を焼いている。

インターンなりエントリー/ジュニアレベルであれば教育すれば良いだけなのだが、経験豊富ベテランという触れ込みでやってきてそれなりの給与をもらっているからタチが悪い。

一度もプレーせずに長年プロサッカー選手として生きたブラジルだかのおっさんのように、きっとこれまでも口の上手さであちこち渡り歩いてきたのだろうと推測する。

奴が入ってきて1年ほどになるが、上司は気づいているし、一緒のプロジェクトで働いたことのある他のエンジニアも皆気づいている。クビにするなり何なり手を打つように直談判すべきか。

2018-06-24

プログラマアニメ好きみたいな風潮

プログラマなら当然アニメ見るよね」みたいな論調の人をたまに見かけるけど、特に前置きもなにもなく「今期何見てますか?」みたいに決めつけないでほしい。昔より遥かにアニメ一般的になったとはいえ、みんながみんなアニメをチェックしてるわけじゃないと思う。

技術者から言われるなら単に「白痴か」って思うだけで済むけど、同じプログラマからだとちょっと不快になる。

別に俺もアニメが嫌いなわけじゃないよ。クレヨンしんちゃんとかたまに見るし。深夜アニメも見たことがないわけじゃないし「こっち来んなアニオタ」などとは思ってないし、幼稚だとも思ってない。

アニメを観てる前提のコンテキストで話されても伝わらないから、プログラマ同士といえども、まずアニメを見てない可能性もあるってことをわかってほしいんだよね。

多くの場合、見てないと言っても「言うほど見てないだけ」と解釈されて、こっちが知ってる前提で話が継続するの悲しすぎる。

本当はもっとこの前勉強したプログラミング言語とかアルゴリズムとか英文法の話とかしたい。

追記

トラバを見て思ったけど、たしかアニメ問題だけではないような気がする。

相手英語を読めるかどうかに関わらず英語サイトを見せたりするし、デザインパターン知識の有無を確認せずに「Visitorパターンで行けそうですね」みたいな話とかするし、なんにせよ軋轢は生まれしまものなのかもしれない。

潔く、バカにされることは受け入れて、普段から「なんですかそれ。わかんない。初めて聞いた。教えて」という白痴モードで接するのが一番いいのかな。

2018-03-18

プログラミング歴とプログラミング能力ほとんど関係無い件について

ほとんどの人はもう既に気付いていると思うけど、あえてこの表題言及している人はあまり多くないんじゃないかと思ったので書く。炎上したら💩なのでここに書く。

結論から言うと、プログラミングを何年やったかプログラミング能力はこのぐらいと言うことは絶対にできない!

これは何もIT業界だけでなく他の分野でもそうだ。たとえば野球とか絵画かにも言えることで、ただ年数を重ねればいいってわけではない。勘違いしてほしくないのは、他の業種ではただ年数を重ねればいいといっているわけではない。

コンビニだったら始めはレジ打ちから入るだろうが、だんだん品出し、他者とうまく調整できv、何が売れるか・何が利益率を叩き出すかを把握し、接客態度は絶えず磨き……というように、能動的にスキルを身につけるなければあっという間に「経験した年数」などというものは何の武器にもならないであろう。(「やっても給料変わんない」とかそういうのは抜きにしても)

IT業界でもこれが言えるのだ。

その証

個人的経験によるサンプルしか無いが、ぼくの経験上では年数が高ければ高いほどいいと思ったことは全くない。もちろん2ヶ月の新人と5年目の人での比較はなかなか難しいが、情熱ある新人プログラマ半年で5年目を追い越すなどということはありふれた話だ。あたか大人小学生中学生さらっと数学英語能力で負けるように負ける。

残念ながらしっかりした実証などはないので、周りの環境がそうではない場合は納得できないかもしれないが、以下は明らかであろう。

経験年数とは時間であり、重要なのは時間を代入すると成長度合を求められる関数(ここではFとする)の違いである。(F: time -> ability)

Fの方が大事理由も明らかだ。timeケチをつけようとする例外を除けば誰にとっても同じであり、おもしろくもなんともない。

Fの次元が違う場合は、能力次元文字通り違う。そのため、かなり重要だ。

プログラミング歴が増えることは恥だと思いたい

プログラミング歴2年だからこんなことを知っている」と周りから評価されるというのは、要は「プログラミング2年生」だということだ。これははっきり言って侮辱である。2年プログラミングをやったから知っているんじゃなくて、2年の間で勉強したことたまたま別の箇所で出現したということだ。決して2年やったからではない。2年の間に獲得したスキルがいっぱいあるからだ。2年は重要じゃない。どれだけやったかだ。2年という期間それ自体は全く重要ではない!

プログラミング歴2年なのにそんなことまでできるのか」というのが真の評価なのだ

これはまあまあ高い評価である。「プログラミングを始めてまだ半年なのにそんなことできるのか」という評価はより容易く得られる。年数を重ねれば重ねるほどこの評価に達するのは難しくなる。したがって「プログラミング10年なのにそんなことまでできるのか」という評価ほとんど得られない。ほとんどの場合、「10年やってるからできるんだな」とか、ひどい場合10年やってるのにこんなこともできない」という評価になる。

これもある種、年数というもの全然重要じゃないとみなされている証左であろう。みんな知らず知らずのうちに周囲の人々の経験年数と能力とでおのおの相関図を作り上げて、標準偏差をなんとなく作り出して、「45歳……クソコード……チーン!こいつは偏差値37!落第!死刑!」みたいなことをやってるんだろう。

プログラミングも慣れてくると、特に新しいことを勉強しなくてもなんとなくできるようになってきはじめる。これが危険シグナルだm

謙虚でありたい

自分プログラミング歴が長いのに、HTTPSの仕組みもTCPの仕組みも詳しく知らず、JavaScriptもまともに書けず、WebAssemblyは全く知らないし、RDBのことは知らないし、もちろんRDB以外のDBちんぷんかんぷんで、デスクトップアプリは作ったことがない、サーバサイドはRailsしか知らない。Railsがどう作られているかも知らない、gitの触りぐらいしか知らない、AWSGCP全然使いこなせない、公開鍵暗号方式もよく知らないし、アルゴリズム簡単ものしかからない。デザインパターン勉強してないし、関数型言語もわからないし、C言語全然読めない、アセンブリはやろうと思ったことすらない、正規表現も複雑なものはいまいちわからないし、機械学習はわからないし、そもそも数学不安で、AndroidアプリiOSアプリもまともなものリリースしたことがなく、エディタは人が作ってくれたプラグインをただインストールするだけで、英語ほとんどできず、セキュリティに関してはザルもいいとこ」

のように自分を見直すべきである。もちろんほとんどの人はそうしているとは思う。そもそも自分プログラミング歴が長いのに」という部分はもはや要らないだろう。

あとはただ穿つだけである能力は、どれだけ、何を、どうやったかとの方と強い相関を持つ。能力とは現在状態であるのだから、強い相関を持つのは最最もである

結論

少年老い易く学成り難しである

一刻も早く「プログラミング歴」でなんとなくの判定するのをやめて、プログラミング歴1秒の人に対しても、プログラミング1000年の人に対しても、そのFを見るようにし、自分はとっとと次元を越えて昇華したいものである

結局、「いっぱいやればいっぱい成長する」という自明結論自体は変わらないんだが(高)

2018-02-16

プログラム設計書とかいもの

最近SE向けに、JavaWEBアプリコードからプログラム設計書を書き起こす作業をしている。

コード自体は今風の書き方で、それなりに読みやすい。そのコードを、日本語文章(たまにフローチャート)に翻訳していく。

基本的に読者は非プログラマーなので、クラス設計原則やら、デザインパターンやらの気配を匂わせてはいけない。通じないし、冗長になるだけだからだ。

辛い。ゴリゴリ精神が摩耗していくのを感じる。果たして、これは必要ものなのか?残念ながら、必要なんだな、今のプロジェクトでは。

いまさらこんなもの書くことになるとは思わなかったなあ…。

2018-01-02

プログラミング初心者の頃の気持ちを忘れた

プログラミング教えてと言われた。

自分PCサーバ立ててドメイン通してアクセスしてみて、HTMLCSSJavaScript概要を教えた。

http://hogehoge.comを叩くとぼくのローカルPC上のHTMLを見ることができるのだ。普通これは感激するはずだ。ヤツは少しも感動しなかったが。

タグのことを教えて、formタグ使ってみて、CSSを教えてセレクタの使い方教えて、なるべくDOMというワードは避けてJavaScriptイベントの追加のしかたを教えた。

で「あとは色んなタグ覚えるだけ」「CSSで色んな組み合わせやってレイアウトを楽しんでね」「あとは色んなイベント覚えるだけだから」みたいな感じ。色んなイベントを追加してもらった。

その後データベースの話をした。

「まずエクセルファイルからデータ取ってみよう(実際はCSV)」「あ、でもこれだと取りにくいし時間かかるね」「しかもこれだとデータ矛盾ちゃうしめんどくさいね」「そこでデータベースですよ」

って言って、sqlite3を教えた。エクセルで「これがインサート、これがデリート」って説明しながら、テーブルレコードSELECT, INSERT, UPDATE, DELETEを教えた。

ヤツは「なんでそんなわかりきったことをわざわざ文字入力するんだ」と憤慨していた。こっちが憤慨したい。

で、次はWebフレームワークの話。まずWebフレームワークを使ってもらう前に、URLを叩いたらアプリケーションが走ることを確認してもらう。僕は「すごいでしょ!!」って言う。

さっきのsqlite3とつなげてみて、データを取得して表示してみた。ここで僕、「すごいでしょ!感激するでしょ!!」って言う。「ふーーん」っていう反応。「データをそのまま表示してるんだからそんなの当たり前でしょ?」みたいな。うるせぇWebサービスなんて大体そんなもんだわという言葉を飲み込みつつ、ここまで3時間

ここで初めてサーバサイドの言語を教える。for-each文、関数までは順調。そしてクラスクラスは若干詰まっていたのでぼくはまず構造体について説明した。

構造体のことはよくわかるみたいだ。まず青赤緑で構成された色の構造もどきを作って、画面に色を出力した。ぼくがこの構造もどきで画面にマリオを描くとヤツは感動していた。

そしてぼくはクラスについて教えた。「この構造体に関数がついてたら便利なときもあるもんだ」って感じ。説明がめんどくさいので「このクラスっていうのが型だよ」とか言っておいた。

共通でいてほしいものもあるけど、共通でいてほしくないものもある」と言って、ぼくはキャラクタークラスを作ってマリオオブジェクトクッパオブジェクトを生成し、FFを究極に安っぽくした感じのフィールドで戦わせた。

ヤツは興奮しているようだった。マリオは負けた。ぼくは「人は目に見えるものしか興味が沸かないんだな」と達観した。

Webフレームワークに戻ってぼくはクラスを使ってViewModel、そしてControllerを教えた。彼はなんだかかなりよくわかった様子だった。ぼくは満足した。

そろそろ5時間になろうとしていたので、ぼくは「あとはデザインパターンと言って、プログラミングしていてよくあるパターンを集めたものがあるんだ」とか「アルゴリズムを知ると色々効率よく書けるよ」とか「非同期処理とかもあるし、とにかく色んなライブラリを試してみて」「他の言語とかも試してみて」とかそんなようなことを言った。

ぼくの仕事は終わった。あとはもうヤツは自分ひとりでなんでもできるだろう。ときどきぼくが質問に答えることもあるだろうけど、ヤツはサーバサイドに必要な大まかな知識を、こんなに短期間で得たのだ。ヤツは優れたエンジニアになるに違いない。ぼくはヤツの家をあとにした。お金ぐらい払ってほしいものだ。

翌日、ヤツから電話があった。

「ごめん、HTMLってなんだっけ……?ていうかファイルってどうやって作るんだっけ……」

ヤツは何も覚えてなかった。俺は発狂した。俺はいったい、何を教えていたんだ。

あと俺、数年勉強しててこれぐらいのことしかわかってなかったのか?そう思って、なんだか猛烈に虚しくなってしまった。

そしてぼくは、二度と人に教えないことを決意した。

2017-12-31

anond:20171228095020

知識としては経営学部学部回生レベルからね。

デザインパターンみたいなものといえばそうだと言える。

その知識を元に、ケーススタディといってビジネスを見て振り返ってというのを繰り返しやるのがMBAだけど、

「生き残ってる」ベンチャー社長で、ある程度まともなのは経営学特にマーケティング知識を踏まえた行動をやらんと生き残れない。

生き残ったのが社長を続けているから、MBAで学ぶ程度の初歩知識はある。

一方、その最低限のマーケティング意識がないのもいっぱいいるか知識としてはやっぱり持っておかないとならない。

ビジネスが完全にわかる奴というのはまあ、たしかに世の中にはいいかもしれない。

いろんな人はビジネスはこんなもんだ。みたいなのを読んでの積み重ねでしかないんだろうね。

まあ、裏張りや「こんなあくどいことしても儲かるオレすげー、世の中バカwwww」みたいな苛立たせるような成金書物もあるからそこはみさだめないと。

2017-12-28

MBA持ってる人と話をしたんだけど

経営学修士持ってるって言ってもこんなもんかよ

絶対オレのほうが詳しいわ(自分が詳しいなんて思ってないけど)

ガッカリだよ

 

そういや、そこらのベンチャー社長の話聞くと皆かなりしっかりしてるけど

ほとんどMBAなんて持ってないんだよね

結局独学、個人資質次第ってこと?

ビジネスちゃんと分かる人って一体どこに居るんだ?

なんかオカシイんだよね、滅多に居ない(そもそも皆興味がない)

 

そもそも、そんなパターン化できるものでもないと思う

喩えるならプログラミングに近い

デザインパターンで全部解決できるわけじゃないのと同じ

パターンでできるなら誰でもできるが、そうなってないというのと同じ)

からこそMBAという「こいつは理解している」という印籠に効力があると思ったんだけど

何、座学受ければ誰でも取れるのかこれ

場所によるとか?

2017-12-14

IT系あるある

ジーパン or チノパン + ワイシャツ

それ以外の格好がなかなか出来ないしファッションもこう、なんかデザインパターンみたいのが欲しいです。(笑)

2017-11-27

子供プログラミングを学ばせる・・・ってやつ

パズルみたいな奴でオブジェクト志向的な発想を学ばせるやつ

あれ本当に効果ある? 

そんなん初歩の初歩で、プログラミングって結局デザインパターンや、アンチパターンライブラリ名前

サーバーデータベースの設定方法や、次々出てくる新しい概念を覚えるという泥臭い勉強必要なわけじゃん

楽しくプログラミングなんかしてたら絶対身につかない知識が実務には必要

パラダイムシフトさせて世界技術の基盤を作るような発想をするにも、やっぱり泥臭い勉強必要

ゆとり教育と同じ失敗やろうとしてる気がするんだけど、あれで本当にいいのか

それよりは大学コンピューターサイエンス科を増やしたほうが・・・

2017-11-22

anond:20171122020027

行き過ぎたオブジェクト指向には弊害があることがわかってきたし、

デザインパターンも、たったそれだけのパターンで何でも解決できるわけがないだろ。

臨機応変もっと頭使えよ。的な論調はあるよ。

考案された時期から考えたら、もう古い技術と言っても差し支えないでしょう。

2017-11-08

anond:20171107110105

> ここ5,6年の悩みで最近はっきりわかってきたんだけど、俺いつのころからかどうやって勉強していいのかわからなくなった。

> 一番大きいのは結婚して子供できて自由時間が減ったことなんだろうけど、でもそれ以前から勉強ぜんぜんできなくなったの。

お前は俺かってくらいまったく同じ状況。なので最近ずっと「俺ってもっと優秀な人間じゃなかったか」って思って自己分析してるんだけど、ここ数年で一気にスキルセットが変わったのが大きな原因かなと思ってる。デザインパターンアスペクト指向UMLプロジェクト管理手法、積み上げてきたものはたくさんあるけど、今はまったく使えない。若者より知識ものすごくあるけど、意味がなくなった知識ばかりなので実質的比較をするとほぼ対等。アジャイルクラウド機械学習・・・新しく出てきて若い世代が中心的に学んできた技術存在を考えると、おっさんたちはむしろ若者よりマイナスになってしまったわけ。知識の量は若者より多いのに関わらず。

なので、勉強をするときも「若者よりスタート地点がだいぶ低い」という観点勉強しないとダメだと言う結論に至った。その方法とは、簡単コンテンツを、大量の時間をかけて大量に吸収する、ということ。

後、子供はもう致命的な。特に休日今までは合計で16時間くらいは勉強に使えていたのが0時間になる。一ヶ月だと64時間くらい消えてるのね。勉強できないってより勉強してない。となると、前述の「大量の時間をかけて」が無理ゲーなので、すでに詰んではいる。

> もう俺は嫁さんと一緒にあと20年近くかけて子供2人育てなあかんからITが好きか嫌いか仕事選べる立場じゃねーーーの!

「すでに詰んではいる」と書いたとおりなのだが、これもまったくの真実。「技術ができない人」が「大金を得なければならない」。しかもそれは自分のためではなく、家族という他人のため。その行為は悪ではなく、善。

驚くべきことに結婚して子供ができると「能力の低下」と「収入の増加」を同時に満足させなければならない。そのためにできた制度が、おそらく年功序列であり、管理職なのであろう。そして今はその制度が壊滅しつつある。それでもこの矛盾と戦わなければならないので、結局は能力がなくても若者からお金を奪っていく方法を考えて、どんな手段を使ってもそれを実践していかなければ家族(言い換えると次の世代)を守れない、ということになるだろう。

管理職になる他にも、自分の持ってるレガシー技術を後輩に強制して、自分レガシー知識有効となる土俵議論を持っていくという手もある。いずれにしてもろくでもない。

2017-02-11

職場の開発スタイルが古すぎて限界なんだが

IT業界プログラマなのですが、どれだけ技術進歩しても何年も同じ開発スタイルから一向に改善しなくて限界を感じています

例えば次の点が挙げられる

バグ個人責任のせいにする

 ・世渡りが上手い奴は口だけ出して手は動かさな

  ・こいつが手を動かすのは最小限で、なおかつビビりなのでよく確認する

 ・手だけが早くリリースしてから考えようぜって思っているタイプバグを出すたびに個人攻撃される

開発プロセスが雑

 ・レビューがない

 ・仕様最初から作るつもりがなく、毎回担当者が長年の勘で仕様を考える

  ・故にどこかで矛盾が生じる

  ・担当者の長年の勘が頼りなので、作り手としては要求に答えるしかない

   ・仕様明確化されていないので、言われた通りに作るしかない

   ・一部しか担当していないので、一部しか知らないのだがそれを「もう何年もやっているのに担当したところしかできない」と言われる

    ・尚、これに対し口答えは許されない模様

 ・仕様がないので自分なりに担当者確認して作る

  ・このあたりはOKなのだが、その内容は一切ドキュメント化されていないしするつもりもない

  ・いつでもこの仕様担当者の気分で変更できる

   ・変更できるのは問題ないが、言い方が「お客さんがバグ報告がきた」みたいな切り出し方

   ・バグではなくただの仕様だし「作る時にそう言いましたよね?」と言ってもドキュメントがないので根拠なし

テストを書かない

 ・開発スピードが遅くなるから理由テストを書かない

 ・というか書き方を知らない

  ・xUnitすら使えない

MVCを知らない

 ・単語は知ってて理解しているつもりなんだけど的外れ(いわゆる Fat Controller が普通だと思っている)

・新しい知識を覚えるつもりがない

 ・自分達で勉強した最新の知識デザインパターン

 ・新人が入ってくるもこの調子なので2〜3年もすると社内の仕事はできるが若いのに技術力は10年以上前技術者レベルになる(仕事必要なことしか知らないのでそれ以下か)

 ・そして、いつまで経ってもこの開発スタイル改善しない

けものフレンズがバズったので、ついカッとなってやった。

2016-11-18

設計について善し悪しを議論をするのは難しい

ブレストとかあるじゃん

あれって、非常に単純なアイディアに対する議論が主なんだよ

構造的になっているような、設計必要タイプの話は中々議論ができない

できるとしたら、その筋のプロ同士とか、デザインパターンが決まったものについてとか、天才同士とか、そのくらいだ

 

からブレストから始めると、構造的な問題に対する話が漏れ

結果「みんなで考える」より「ひとりを中心にして設計する」方がうまくいくケースが有る

そして、そういうケースは得てして非常に重要ものだったりする

(例:物語脚本組織づくり)

 

何かしらの設計に携わる人は、この件について知っていたりするものだが

多くの人は「みんなで知恵を出し合えば解決する」と勘違いしている

そういう風にして手詰まりになるシーンを何度か見たことがある

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