はてなキーワード: Rubyとは
https://www.youtube.com/watch?v=yhDLmGpjdms
これよりもっとひどい動画はごまんとあるが、ここまでタイトルで煽っている以上指摘するわ。
プロフィール見るとCTOを経て独立してプログラミングスクールの会社やっているっぽいけど、すごい時代だな。
晒しになっちゃったけど、他にも有名(と思われる)プログラミング系YouTuberが実際にコードを書いている場合でひどいのはザクザク見つけられるから、見つけてため息をつくといいと思います。
RPAで疲れ果てた方の日記と、それを見て書きたくなった人の日記を見て書きたくなったので。
しばらくフリーターして社会復帰、プログラミングやりたくてIT業界に転職した。
社会復帰のタイミングに職業訓練校でJavaScriptを勉強しながら就活、入社即RPAの現場に単身で放り込まれて今に至る。
客先常駐でシステム開発してる会社だと聞いていて(Java,C+,Rubyあたりとか)、
3回くらいあった面接で一度もRPAのRの字も出てこなかったが、
内定が決まり入社までの待機期間中、勝手にセッティングされた客先との面接で初めてRPAの話を聞かされた。
(今思うとここで断れればよかったのかもしれないが...)
入社後即放り込まれ、仕方なしに頑張るかと思って向き合ったらとんでもなかった。
RPAエンジニアとして雇われてる数人の中ですら共通のルールが存在しなかった。
各エンジニアが作ったもの、非エンジニアの客先社員が作ったもの、過去在籍していた人が作ったもの等々...
何を基準にしていいかもわからないし、というかそもそも基準がない。
現担当者はRPAごと業務を引き継がれたけど、RPAの中身は知らない。その業務のマニュアルも存在しない。
エラーが出ても何が正しいのかわからない、けど「エラーが出ました」と問合せが来る。まず正しい挙動を教えてくれないと修正もできん。
私が担当することになった部署のRPAを作っていた前任エンジニアが画像マッチング大好きマンで、
WindowsのバージョンアップとIE終了に伴う改修が地獄のような作業だった。
部署によって端末環境がかなり違うという客先環境も相まって、画像マッチングが多用されているシナリオに拒否反応が出そうになる。
それぞれがどんなRPA作っててどういうエラーに対応したか、みたいな話をする機会がない。
故におそらく似たようなRPA作ってるけど、それぞれが各自で作ってるからすごい無駄。
多分展開できたものいっぱいある。
等々、正直まだまだ書けるけど書き出したところで別に何も変わらないので割愛するとして。
単身で放り込まれたもんだからまともなフォローもなくかなりしんどかったけど、
なんとかこなしてやっと慣れてきたところで、今後のキャリアを考えたら鬱々としてきた。
今後長いスパンで見たときにRPAエンジニアが必要かと言われるとそうでもないだろうし、
かといってRPAエンジニアの数が少ないっぽい今、即戦力なら欲しいところは多分あるわけで。
RPAから抜け出せずにずるずるとRPAエンジニアやり続けて、
取り返しのつかない年齢になってRPAが廃れて...とか考えただけで怖い。
でも職業訓練校レベルのコードしか書いてなくて、業務でコード書かなくなってしまった今
HTML/CSSですら書けるか怪しいみたいなレベルになってきてるのに
RPAから抜け出せるのかという不安も強いし、今後どの方向に舵を取ればいいのかわからなくなってきた。
それにしても、職業訓練校やら独学やらで一通りHTML/CSS触ってJSに触れてたからなんとかRPAしてこれたと思ってるけど、
これを「通常業務やりながらRPAも担当してね」とかって振られたらと思うとゾッとする。
スペックはアラサーのIT系人材。Web系はだいたい一通り触れてきてフロントエンドもバックエンドもある程度できるけどインフラは最低限くらいにしかできない程度に苦手。言語はPerlとJavaScriptから始まってPHP、Ruby、Python、Go、TypeScriptあたりは言語レファレンスを見なくてもある程度は書ける。非WebだとC++とかも一応書けるには書ける。フレームワークで言うとRailsとかDjangoみたいな全部込み込みのものからFlaskとかpeeweeとか選定して作るみたいなレベルまで色々経験してきたし、フロントエンドもnodeとio.jsが喧嘩してた頃からAngularとかBackboneを経由してReactやVueなんかに触れてきた。某転職サイトでは得意な言語は一通り偏差値65-70で某ポートフォリオサイトの技術力スコアは3.6くらい。運良く趣味やらバイトやらでWeb系をやってきたから外向きに見せられる実績もある程度あるしエンジニア人材マーケット内でもそこそこ需要があるといった感じ。ずば抜けた才能があるわけではないけどどんな現場でもそれなりにスキルを発揮できる器用貧乏タイプだと思う。
そんなこんなで博士に至るまでIT系のスキルを活かしつつだいぶウェット寄りの分野でプログラミングを駆使して色々なことに取り組んでた。民間のエンジニア人材としては平々凡々でも周りがプログラミングできない連中だらけのアカデミアの世界では神扱いされてちやほやされた。そんでもてはやされて勘違いして工学じゃなくて科学の博士課程に進んだのが間違いの始まりだった。
身バレするのが嫌だから詳細は伏せるけど、まあパワハラアカハラなんて日常茶飯だった。指導教員はまともに指導なんてしないし周りの教員たちも工学的なことばっかやってるのを見て好き勝手言ってきた。正直進む道を間違えたのは自業自得だけど、そのくせ「せっかく進学したのにやめちゃうの?」みたいなこと言って引き留めてくるからタチが悪かった。今からして思えばプログラミングができるレアな便利人材を手放したくなかったんだろうなって感じがする。
そんなこんなで博士の終わりが迫ってくる頃にはアカデミアに対してこれでもかというくらい嫌気が差していたけど、それでもやりたいことがあるから一応就活はアカデミア系と民間系で両方やってた。どちらもオファーが来たけど結論から言うとお話にならないくらい民間の方が条件が良かった。
まず給料は民間が1.5倍以上、アカデミアの技術職との比較だと2倍以上の開きがある。しかもこれは「民間の一番下」と「アカデミアの一番上」を比較した数字でそれぞれ逆をとったら正直目も当てられない。その上福利厚生もさまざまな手当も民間の方が条件がいい。給与の伸び代も民間の方がいいし就労条件も民間の方がいい。そもそもアカデミアでフルリモート可なんて存在しないんだから勝てるわけがないんだけど。その上で民間は原則として終身雇用に対してアカデミアは任期付きのポストばかり。就活を始める前からわかってたけどいざ現実として待遇の違いを突きつけられるともはや笑うことしかできなかった。
「それでもアカデミアは自分の研究ができるんだからいいじゃないか」と言う意見を目にするけど、結局はPIとして独立するまでは他の先生のラボで雇われになる。その間にうまくやらなきゃ一生そのまま下請け仕事をし続けることになる。そしてたとえ独立できたとして、選択と集中の名の下に文科省にとって都合のいい研究テーマを立案しなければまともに研究費を取ることすらできない。大口の予算を取ろうと思ったらいかにビッグマウスで役人を丸め込んでそれっぽいことをやれるかで全てが決まる。
自分が外れ値であることは否定しない。プログラミングが楽しくてWeb系の技術が好きで、可処分時間を使って夢中になって勉強したり色んなものを作って遊んだらして過ごしてきたからこそ今がある。でも正直少しでもプログラミングができるならアカデミアに残るより民間に就職した方が待遇もワークライフバランスもいい。きちんとリサーチすればカルチャーだってすごくいい会社はたくさんある。
それを承知の上でアカデミアに残る人は正直すごいと思う。自分がその立場にいることを想像したら気が狂いそうになる。もし似た立場で迷ってる人がいたら心から伝えたい。アカデミアやめて本当によかった。
言わんとすることは察するが、おとなしく Python をやれ。挫折しにくいから。個人的には Ruby > JavaScript > Python > PHP > Perl だけど。
ボクチンは「来週までにAWSのEC2インスタンスをVPC でつないで、グローバルIPをとって公開する方法を勉強してきてね」「フロントエンドは不要になったから、来週までにスプリング勉強してきてね」「なんか Python が必要になるから、勉強してきてね。だいたい Ruby とおんなじだから週末でいけるよね?」という感じだったな。
自分が業界に入った頃はVisualBasic使ってWindows用の業務アプリ作れますって人や会社が大量にいたんだけど、今はそんな需要はほとんどないわけで
なんで、PythonやらJavaScriptやらRubyが初心者向けと勧められちゃうんだろう。
a = 100
puts a
とか打ち込んでぱっと実行結果が見れるから、その瞬間は簡単に思えるけど、20行やら30行やら100行とかちょっと行数が増えるだけでこれらの言語ってJavaやらC#に比べたら格段にコード書くのが難しくなるよね。
初心者が数行程度のコードを書いて「Python簡単じゃん!」と騙されるのはわかるけど、人にどの言語がいいとか勧めてる人ってそこそこコードを書いてる人らだよね。
JavascriptはTypeScriptが生み出されて、PythonやPHPは型宣言が取り入れられて、Rubyも型チェックを取り入れようって話が出てる。
某話題の書籍を買って読みました。ひととおり読んだのですが、話題の1章を読みつつ取ったメモを、本が回収される前に置いておこうと思います。
ちなみに最初は電子書籍で読んだのですが、回収かもって話を聞いて紙も買いました。
以下にメモをそのままのっけるので、たぶん書籍と照らさないと意味不明だと思います。
・Web1は「1970年代から1980年代」というのが若干謎ではあるが、この本ではそういう定義だとおもって受け入れる余地はあるか。実際、列挙されているTCP/IP・SMTP・HTTPの最初のRFCは70~80年代
・HTTPはWebサイトの「構築」をするものではない(Webサイトのデータを取ってくるためのプロトコルである)
・TCP/IPの4層モデルとかOSI参照モデルとかを意識しているんだろうけれど、いまひとつWeb2とWeb3の対比ができていない。また、後段で「ブロックチェーンもプロトコル」と主張する割に、このLayersにも「Protocol Layer」が存在しており、いまいち言いたいことが伝わってこない
・Web2 Layersの雑さは見ての通り。「中間のレイヤー」としてなにを想定しているのかが気になるところ。「プラットフォーマーの上に載っている」という結論ありきで作られた図のように思える
・Web1の例としてHTML/CSSのWebサイトのことを提示しており、それはそれで正しいのだが、冒頭のWeb1は1980年代のプロトコル云々というところと整合しない。
・JavaやRubyはわかる C++もそりゃあたくさん使われてるわけだが、この並びで出てくるのはちょっと違和感。PHPとかは?
あとP2PはべつにWeb3独自ではない SkypeとかWinnyとか、クライアント・サーバではない仕組みは2000年代からいくらでもある
・このへんはあんま詳しくないのでよくわかんなかった そういえばログインIDにメールアドレスを使わせるようになったのってなんでなんでしょうね
・この書き方だとSNSログインすると情報収集できそうに読めるけど、SNSログインを介したからって即ログイン先の情報をプラットフォーマーが集められるわけではない
・ブラウザのとこはそうだね~っていう感じだったが、Firefoxがハブられてるのがかなしかった オープン云々のはなしをしたいならMozilla財団の果たした役割は相当に大きいと思うのだが、(この本に限らず)無視されてることが多い
・OSの部分は突っ込みどころがいっぱいあるしスクショがバズったのですでに突っ込まれている
・あくまで例示で出てきてるだけなので本質的なところではないし、よくあるまちがいではあるのだが、POPはどちらかというと「受信したメールを取ってくるため」のプロトコルと呼んだほうがいいと思う じぶんが使っているメールサーバ(というかMTA)までメールが届くのはあくまでSMTPが使われている 「プロトコルが一緒じゃないと~」という文脈で考えると、いったん向こうのMTAに到達しさえすれば、読み手がPOP3で受信しようがIMAP4で受信しようがどうでもいいわけで、例示としてあんまりうまくない
・唐突にICMPが出てきてびっくりした 重要であることはまちがいないのだが、あんまり「プロトコルの例」として出てくるとこはみないので
・後段で「Web3ではいろんなプロトコルがあるんですよ~」という話をするんだったら、ここでWeb3のプロトコルとしてBitcoinとEthereumしか出さないのはなんか話が通りにくいのではないか