  |
はてなキーワード: スクリプトとは
添付zipに後でパスワード送りますメソッドは案外意味がある。メール盗んでるような連中はひとつひとつメールを見てるわけやなくて取れた添付ファイルを片っ端から辞書解析してくような奴が大半だから。盗める添付ファイルは膨大な量なんである程度簡単なパスワードで破れないならすぐ諦める、でないと計算機資源が足らんし、そもそもその程度でも手に入る攻撃対象は十分あるから。だからある程度長くて複雑なパスワードつけときゃメールで後でパスワード送るやでってやっても大半の犯罪者からは守れる。メールのスレッド追ってパスワード部分だけ抜き出すようなスクリプト使ってる犯罪者はそんなおらんからな。犯罪者の奴らが量子コンピュータで暗号解くとかめっちゃ賢いAI使うとかし始めるまでは今のままで安心しててええやで。
努力不足でSESにしか行けなかったというツイートが話題になっていますね。
件の人に限らず、スクール卒業者が就職できないやら、採用したけど使えなかったとかという話をよく聞くので、そんな悲しいミスマッチを減らし、この業界を目指す人が希望と勝算をもってチャレンジできるようになることを願って思っていることを書いてみようと思いました。
業界に入って十数年、メガベンチャーで働きGAFAの関連企業から1X00万円のオファーを貰うくらいのスキルと経験はある。もちろん開発のスペシャリストとして。
新宿の雑居ビルにオフィスのある中国人が経営するSES会社からキャリアをスタート。最初の会社は雇用保険も払ってなかった。
新卒または第二新卒、文系または数学が苦手、プログラミング未経験者でスクールやサロンに入ってプログラミングを身につけて働きたいと思ってるひと。
理系やプログラミング得意な人は、学生ならインターン、働いてる人はなんでも良いからスクリプトで業務改善すれば実務経験になり、そこからならどうとでもなるのでこの記事は参考にする必要なし。
ふたこぶラクダ理論というものがあります。(https://ameblo.jp/bradnine/entry-11911830387.html)
要約すると、出来る人と出来ない人がいて、何が要因なのかわかっていないし、出来ない人への教え方も確立していないとのことです。
学び始めてすぐに判断を下す必要はないですが、スクールのカリキュラムを終える頃には周りとの成長スピードの差で自然に理解できるかと思います。
しかし、もし適正がなかったとしても悲観するのはまだ早いです。
プラグラミングの適性がない人にもこの業界にはポジションがある。QA、PdM、PjM、UIデザイナー、UXデザイナー、カスタマーサクセス、営業、採用、などなどいろいろあります。
なにはともあれ3割くらいは可能性があって外れても選択肢があるんですからポジティブに受け止めましょう。
エンジニアの生産性の差は10倍や100倍にもなると言う話は聞いたこことがあるかと思います、底辺と天才を比べた極端な話だと思いますよね？実はこれありふれた話です。超有名ベンチャーで難しい採用試験を潜り抜けて即戦力採用された人たちの中でも100倍の差があることもあります。それも瞬間風速的な話ではなく、年間の変更コード行数を計測してそうなります。10倍の差はもっとありふれた話です。
さてここまではプラス面だけの話ですが、マイナス面も考える必要があります。
あなたが無事現場に入ってわからないことを教えてもらう必要があるとします。面倒見のいい先輩がなんでも聞いて良いよと言ってくれたので、質問をして、3時間先輩の時間を使ってしまいました。先輩は100倍エンジニアだったとすると、その3時間であなたの二ヶ月分の作業量が消し飛んだ計算になります。あなたはそれに見合った成長をして恩返しできますか？
ちなみにそれくらい能力差があっても給与はあまりかわりません。良くて倍くらい。同じ給与ってこともまぁよくある話で、多重下請の現場では逆転してることも珍しくはありません。
そろそろ本題に近づいてきました。
ここまでの話を踏まえてどうするべきだと思いますか？
特別なことでも難しいことでもなく、いたってシンプルです。それは「足を引っ張らない」ことです。大抵の現場では初心者に毛が生えたような人にアウトプットを期待していません。ある程度の教育期間をとった後で普通の人の半分でもアウトプットを出してくれたら恩の字です。
あなたが天才でなければ、まずは自分でアウトプットを出すのは一旦諦めてください。先輩の時間を増やしましょう。例えば動作確認や他チームやステイクホルダーへの連絡、文書作成など、100倍エンジニアでも生産性が変わらない業務を肩代わりして先輩が開発にかけられる正味の時間を増やしましょう。これが現段階では正しいチームワークです。100倍エンジニアの時間を奪って質問するくらいなら、10倍の時間をかけて一人で調べた方が、10倍生産性が高くなります。聞くとしても調べた上での答え合わせと間違っていた時のヒントだけにしましょう。個人の学習効率をだけみてもそっちのほうが効率いいです。理解できない人には独学大全がオススメです。
ろくに動作確認をしていない可読性の低いコードをプルリクに出して、レビュワーになった100倍エンジニアが仕様確認したりローカルで動作確認したり、あまつさえバグを見つけてしまうなど、最悪です。
初心者だから間違えてもしょうがないというのは正論です。しかし、プロジェクトの時間とコストを考慮すれば逆の結論になります。あなたのアウトプットが数倍早くなろうが遅くなろうがプロジェクトには影響がないのです。学習時間とリスクを考慮してそういうふうにタスクを組んでいます。数倍時間をかけて慎重にやって良く、マイナスを生まない事を考えれば、初心者こそ絶対にバグを出してはいけないという結論になります。0は無理でもそういう気持ちでやりましょう。
ここまでは現場に入ってからの話でした。皆さんは現場に入る方法を知りたいと思いますが、もう少し辛抱してください。敵を知り己を知れば百戦危うからずの故事もあります。もう少し敵を知ってから戦術を立てましょう。
デスマーチと呼ばれているものには2種類あります。一つは定義通りのデスマーチ (https://ja.m.wikipedia.org/wiki/デスマーチ )。もう一つはデスマーチの要件を満たさないが、関係者の能力不足によってデスマーチの様相を呈しているもの。実は前者はとても希少で、世の中のきついプロジェクトというのはほとんど後者だと考えてください。
様々な点で両者は異なります。
真のデスマーチはほとんどの場合技術的な問題ではなく政治的な問題で発生します。そのため予算は潤沢ではないが常識的にはあり、技術は枯れてリスクが少なく確かな効果が確認されているものが採用されていることが多いです。工学的なアプローチで生産性を向上する仕組みなどが取り入れられていることもあります。管理プロセスも機能しておりコンプライアンス違反も少ない傾向があります。政治的な理由でプロジェクトが延長されている都合で、PMがプロジェクトを終わらせたいと思っていても、予算がある限り新しい要件が発生しつづけて終わらないという状況も発生しえます。こちらのタイプに参加するメリットとしては、よく管理運営されたプロジェクトを体験できる点、ドキュメントがしっかりしている点、低スキルの人が参加することを考慮して仕組み化されているのでキャッチアップにかかる時間が低いなどがあります。
なんちゃってデスマーチは技術力や要件定義能力、集団の合意形成能力などの不足によって起こります。PMやステイクホルダーは赤字を垂れ流すプロジェクトを早く終わらせたいと思っているので多少納期が伸びても必ず終わります。プロジェクトを終わらせるための提案であれば下からの意見でも柔軟に対応してくれることもあります。新しい技術と古い技術が混在していたり、新しい技術を採用しているのに使いこなしていないこともあります。CI/CDや自動テストが無い又は不十分な現場も多いです。こちらのメリットとしてはスタンダートが低いのでキャッチアップ戦力になれるまでの時間が短かったり、小さな労力で大きな生産性改善ができ職務経歴書に書ける良いエピソードが作りやすいといったことが挙げられます。
また両者には人の出入りが激しいという共通点があります。そのためドキュメントの有無にかかわらず新しい人が参加し、教育や環境構築を行いタスクを振って実務を行うという、一連の受入業務に現場の担当者が慣れています。またこれは両者それぞれのところで触れましたが、理由はそれぞれ違いますがキャッチアップして戦力になるまでの時間は小さいという共通点があります。
デスマーチでは残業が多いと思われていますが、新人は戦力として期待していないので残業する必要はないです。マネージャーからすると、無駄な残業代は払いたくないし事故って仕事を増やすリスクも嫌なので、1秒たりとも残業してほしくありません。早く帰ってリフレッシュするなり自習するなりしてプロジェクトのリスクを減らしてください。
そのため、デスマーチに入って残業というのは底辺層にとってはほとんどの場合杞憂です。テスト要員としてでも残業を頼まれたら戦力に数えられている事を喜んでも良いと思います。
翻って比較対照としてみなさんに人気のあるWeb系企業を考えてみましょう。GoogleやNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています。共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルはピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります。開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。
ここであなたが採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう？どちらを採用したいですか？
ここまで書いたことを理解して謙虚に面接を受ければそう悪い結果にはならないと思います。
現場の技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやすい環境を探しましょう。
正確にはPHPのビルトインサーバーでindex.phpなどのルーターを使っていると、URLパスに.(ピリオド、ドット)を含むリクエストが
cssやjsなどのリソースファイルへのアクセスだと判定されて、ルーター(index.php)がパイパスされPHPが実行されない
という現象に遭遇した。
これはビルトインサーバー起動時に明示的にルーター(index.php)を指定することで回避できる。
明示的にルーターを指定すると、リクエストが必ずルーター(index.php)を通るようになる。
上記の対応だけだと、今度はcssやjsなどのリソースファイルがほしいだけなのに、必ずindex.php呼ばれてしまい通常のファイルが取得できなくなってしまう。
https://www.php.net/manual/ja/features.commandline.webserver.php
の例3の通り、画像やcss,jsなどのリソースへのアクセスの場合は、return false; でルータースクリプトを強制停止すると、PHP処理がキャンセルされてビルトインサーバーはファイルなどのリソースを返すようになる。
よく「学問は役に立つことが重要なのではない」などと嘯く人がいるが、これは間違っている。学問の価値は役に立つかどうかで決まる。
まあ、大人になる過程でこういう「他人と違うことを言ってみたくなる時期」があるのは、別に悪いことではない。
しかし、高校生や大学生1, 2年生ならともかく、もうすぐ社会人になる人や既に就職している人がこういうことを言っているのは恥ずかしいことだ。
実際、プロの研究者なら誰でも知っていることだが、学問の世界ではその研究が役に立つかどうかは常に重視される。
自身の研究が既存の研究とどのように関連し、他の研究にいかに貢献するかを示すのは、論文を書く際の一般的なマナーである。他にも、研究予算の申請、大学教員の採用などのあらゆる場面で、「役に立つか」は重視される。
大学などの研究機関や国は別にボランティアで教員を採用したり予算を出しているわけではないのだから、これは当然のことである。
たとえば、以下のPythonのスクリプトを実行すれば、1億個の定理を証明した数学の論文が作れるが、それを投稿しても受理してくれる学術誌はひとつも無いだろう。学問的に何の価値も無い、つまり役に立たないからだ。
[print(f'{n} · {m} = {n * m}') for n in range(1, 10001) for m in range(1, 10001)]
要するに、研究者はこういうクズ論文ではないきちんとした研究をする必要があるし、その研究に価値がある、つまり役に立つことを必ずしも専門家とは限らない人に示さなくてはならない。
荒らされる側→反応すれば荒らしは活気づくので我慢して無視(無視でいなくなるわけじゃない)、粛々と通報を続け、見えないふりをする機能を使う
荒らす側→飽きるまで荒らせる、仲間を呼んで荒らせる、スクリプトで荒らせる、規制されたらルータ再起動したり他のWi-Fiスポット使ったり別の端末やPC使ったり串を通せばいい、特定怖いならtorだってある、ソーシャルエンジニアリングで運営側に潜り込んでサイトやコミュを破壊することもできる
何から何まで荒らしの方が得かつ、荒らしが負けないようになってる
荒らされる側は我慢して我慢して、いなくなるのを願うか、なんとか来れないようにするしかない
でも我慢して消えるとは限らないし、来なくなるように対策してもそれを乗り越えてくる
「荒らしは無視すれば飽きていなくなる」なんて言うが、俺は自分の好きな作品のコミュニティを数年近く荒らされ、今もその廃墟で荒らしは楽しく一人遊びしている
