はてなキーワード: Bootstrapとは
冠婚葬祭以外でスーツもろくに着たことのない人間が、まともな職業に転職することは可能ですか?
自称・ベンチャー企業に来て後悔している、というか恨んでいる。自分のいたベンチャー企業なんて、反社会的勢力 隠れ蓑でしかなかった。そこで得たもの、というものはなくて、むしろ父親と学歴と情熱を失った。 だからベンチャー企業とか NPO なんかに社会的な価値を見出して入社する必要なんてない、むしろ新卒採用では JTC に入れよーという話をしていこうと思う。
元スレは
https://anond.hatelabo.jp/20220613020726
https://anond.hatelabo.jp/20220614002648
です。
国立医学部を目指して多浪し挫折したあとに入った大学は早慶未満マーチ以上の偏差値の大学だった。そのため、周りは年が若くなじめないままサークル勧誘期間が終わってしまったのであった。まちがいなく大学内では浮いた存在であったし、自分も馴染む気がなかった。当時の言い方をするならば「ボッチ」であったか。大学に入ってすぐに、一緒に入学した同期の入るだろう会社には入社できないのが自覚できたので、授業が終わったら大学図書館 or バイト先にそそくさとむかっていた。幸いにして、高校時代はプログラミングを部活でしていたので、どこにいっても「卒業したら、うちにこない?」と言ってもらえた。自分は富士通とか野村総研なんかは年齢制限で入れないけど、飯を食べるには困らないだろうな、という確信はその当時に得た。大学の情報工学の内容は高校時代に習得した内容よりも劣っていたので馬鹿にしていたのは、後でボディブローのようにこの怠慢は効いてきた。ここまで書くと大凡のスキルはコーダー程度であることは察していただけると思う。当時に十分にかけていたのは Ruby, JavaScript, Java, PHP と Objective-C、MySQL といった応用領域ぐらいで、大学でやるような R や Haskell なんかの基礎領域は習得してないで、アルゴリズムの勉強はさっぱりだった。まぁ、あんまり優秀な学生ではなかったと思うが、それでも情熱はあったとは思う。真面目な学生ではなかったが、教授には可愛がってもらった。
これが、当時の自分の心境とスキルである。ここから冒頭に書いたような人生がスタートする。あれは、記憶が正しければだけれど、twitter のリプライだっただろうか。当時の自分は他人の設計書を基本として書くということにうんざりしていた。いつの日にか自分の書いたコードで上場するという目標のために本物のベンチャー企業で上場する時を共にしたいというのに、どうやったらそんな会社を見つけ出し、入り込めばよいのか皆目見当がつかなかったのだ。それで、twitter のアカウントを手がかりに、あらゆる募集サイトに「プログラミングする企業に入りたいです」という書き込みをした。なんなら、増田にすらその書き込みをした。それで、色々な人から「うちに来ない?」というリプライをいただいた。正直、嬉しかった。それで、そのうちから「選ぶ」という選択をしなかったのは間違いだった。当時の自分は、それをせずに「サイバーエージェントに紹介しますので、とりあえず勉強会に来ませんか?」という書き込みをみて、ふらふらと雑居ビルの一角にある共有オフィスへと出向いてしまったのだった。タイムマシンがあればこの日に戻って止めると思う。それぐらい後悔する日々が始まるとは当時は思わなかった。
もうすぐ真冬になろうという頃、「サイバーエージェントの正社員になれるかも」という期待で、列車に揺られて前記のビルへ向かった。期待とは裏腹に、妙に古臭いビルであった。ベルを押して、勉強会だという部屋に通してもらうと、若い学生たちがそこにいてプログラミングを勉強しているという。正直、自分も医学部さえ目指さなきゃこういう生き方もあったのだろうな、とは羨ましく思った。自分をオファーしたという人(O氏)は、この勉強会の座長だという。「私は人工知能を研究しており、アメリカで博士号を取得した『天才』数学者で、日本を活気づけるために母国にもどり、この会社を立ち上げました」という。サイバーエージェントではないらしい。あれ?、とは思った。まぁ、無下にはできないので、そこで課題を出されたのを5分ぐらいで終わらせた。伊達に何年もプログラミングをしているわけじゃない。ループで書くべきところを、再帰で書いた。すごいでしょ、オレっちとね。「できました、見てください」というと、O氏はこう言い出した。「ナニコレ?」とO氏。「ええ、再帰ですよ、漸化式みたいな?」と自分。出力は合っているので、O氏も認めざるを得なかったらしいが顔が険しくなっていく。どうも機嫌を損ねたらしい。そうすると、O氏は自分を別室に呼び出して「履歴書は?」と聞いてきた。「勉強会ですよね?」と返すと、「いいから、履歴書!」と言う。にっちもさっちも行かなくなったが、共有オフィスの他社の中国人職員の方が機転を利かせて仲裁してくれた。「そんなに言うのなら、彼にポートフォリオを作らせてみて評価してはいかがでしょうか」と。
イライラしながら帰宅したあと、もう二度と見たくもないO氏の顔とサイバーエージェントの正社員というものを天秤にかけたとき、やっぱりサイバーエージェントにいきたいなーと思った。というか、実は当時に DMM のオファーもあったのだけど、サイバーエージェントの方が良いと思って辞退した。このクソ人間(O氏)を認めさせたら、サイバーエージェントで働けるというのは魅力的だった。それで、Android(Java) + iPhone(Objective-C) でマルバツゲームを作り、 Bootstrap + jQuery と Ruby on Rails と MySQL で集計させてスコアを比較させる、そしてサクラVPSで CentOS で運営するというプロダクトを持っていった。時代を感じますね。閑話休題。ソレを持っていたら、O氏は今回は前回と性格が違った。いきなり、怒鳴りだすのだ。ポートフォリオを見ないで。いわゆる「良い警官・悪い警官」というやつをやろうとしたのだろう。当時はそれがソーシャル・エンジニアリングだと気がつけなかったが、いま思えば以前からナンパとかで良い思いをしていたのだろう。後で書くが、彼はロリコンだ。専門に人工知能を掲げているが、本当はチヤホヤされたいだけで自分は努力せず、インターンの学生にタダでプロダクトを作らせて「弊社は凄いです!」「あわよくば上場して金と名誉はゲット」、そんでもって若い学生のインターンとセックスしたいという真正のクズ野郎だった。自分の深層意識で「こいつはヤバいやつだ」というアラートはビンビン鳴っていたが、「サイバーエージェントの正社員」というニンジンが目を曇らせた。
そのあと、一月ぐらいはそのクソ会社でタダで自社サの修正をやっていた。こんなのもできねーのと思いながら。ある日「別の会社に行こう」といわれ、面接をうける。なぜか O氏も同席で。話を聞いていると、派遣させられるらしい。派遣登録もしてない会社が。「サイバーエージェントじゃない!」と抗議をすると、「俺に恥をかかせるのか!東京で働かせなくするぞ!」と脅され、派遣きまったあとで、履歴書を無理やりかかされた。給料はホームページに書いてあった額の半分、社会保険は無し、年金もなし、保険書もなし、という最悪な条件だった。派遣先はキツかったが、優しかった。それに、派遣当日から転職のオファーをもらった。記憶が正しければ、平日に働いて、土曜日は帰社日、日曜日は勉強会に出席という日々だった。本当に休む暇がなかった。平日はほぼ終電だったのに、土曜日に東京の端っこにこいとか、日曜日は勉強会だから出席しろ、とか本当に辛かった。それでも派遣先の会社には迷惑をかけたくなかったので、期間が終えるまでは必死に働いた。そして、O氏から逃れるために「あなたとは信頼関係が築けない」という文を書いて退職した。そのあと、自分は大学にも行かないで、別の会社に就職した。あと、O氏は給料を払わなかったので、辞めた後に圧力をかけて支払ってもらった。
プログラミングのスキルは働いてもスキルが付くということはなく、自学自習を続けないと上場するのに必要なスキルは身につかないというのもわかってきた頃、父が死んだ。事故死だった。自分は医学部に行けなかったことの申し訳のなさに、東京の大学に行った後は父を邪険に扱っていた。とても後悔した。それで、半年ぐらい真面目に勉強して私立の医学部に入学し、医学部生として留年しない程度には進級はした。しかしながら、ふと寝る前に「プログラマーでいたかったな」と思うことは毎日のようにある。もう医師になるつもりで、プログラマーに戻るつもりは無いが、それでもプログラミングのことは好きで、毎日1時間は時間をつくって勉強している。好きなんだよな、プログラミングが。
最後に、O氏についてだ。あまりに犠牲者が多すぎるのでネット上で事実を書いていったら、裁判所から開示請求が来てしまった。だからここでは本名と社名は書けない。だけれども、若者たちに「ホイホイベンチャー企業にいくと辛い目にあうかもよ?」っていう事例を例示しなきゃ、とは思うので「ヤバいベンチャー企業の実態」について書いていこうと思う。
...という感じ。だから、基本的にベンチャー企業に期待しないほうがいいよ。下手をすると、犯罪の手助けをするようなつらい思いをするよ。もし、仮にベンチャーに行くなら、高給かストックオプションはマストで行こうね。おじさんとの約束だよ。
プログラミング未経験から1ヶ月ほどで、将棋の評価値の新たな方法でのグラフ化を行うPythonツールを作った。
https://github.com/k-the-p/notherscore
この記事は2本立てです。プログラミングより結果のグラフや将棋に興味がある方はもう一方の将棋編から読むことをおすすめします。
未経験から1ヶ月!Pythonで観る将ライフを向上させた話(将棋編)
AIはわれわれアマチュアの将棋への親しみを大幅に向上させてくれた一方で、棋士が悩みに悩んだ結果として評価値が下がる手を指してしまったときに、「悪手きたwwww」と騒ぐ主にABEMAのコメント欄には忸怩たる思いがあった。
とはいえ、もう評価値を知らなかった時代に後戻りするなんてことは誰にもできないだろう。そして、電王戦から将棋にハマった自分自身としても、AIを否定はしたくない。
であるなら、AIを用いた新しくよりよい将棋の楽しみ方を探っていくしかないのではないか。
以前から私は、「AIの手を指せるなら人間も苦労しないんだよなあ」と思っていた。あるとき藤森哲也先生がYoutubeチャンネルで言っていたことを聞いて得心がいった。「AIの一手は最強の一手なんです。確かにプラス1000点になるけど一手間違えた瞬間にマイナス何百点になるような綱渡りの手。それよりもアマチュアの皆さんにはプラス数百点で得は少ないけど安全な道、最善の一手を学んで欲しい」(大意)と。
ここで言う「最強の一手」に人間にして最も近いのは紛れもなく藤井聡太四冠であろう。藤森先生はアマチュアに向けて喋っていたが、その葛藤は間違いなくプロの中でもあるはずである。渡辺明三冠が言うように「藤井くんと全く同じスタイルを今から目指しても絶対藤井くんより強くなれない」のは自明であるからして。
私はここにドラマがあると思う。また、最強の一手と最善の一手が等しく「いい手」に見えてしまうわれわれアマチュアとしては、そこを機械に教えてもらえるのであれば、棋力向上にも繋がりそうである。
第1候補手と第2候補手の評価値の差を取ってグラフ化すればよさそう?
(差が小さければ手が広い、差が大きければ絶対手に近い、綱渡り)
目指すのはあくまで便利な将棋ツール。将棋AIを作りたいわけではないので、将棋AI自体は局面を入れたら評価値を吐く謎の箱という扱いでよい。
グラフ化や数値の扱いだけでなく、将棋AIとのやりとりをやってくれるあれこれもあるようなので。
あと習得が楽だと聞いた。その話を教えてくれた人はもう10年間英語学習法をブクマし続けてるけど。
あと「読みやすいコードじゃないと動かない」って設計思想がかっこいい。ついでに言うといわゆる「おまじない」が少なそうなのも魅力。(CのHello worldで挫折した経験あり。studio.hって何……)
プログラム講師をやっている?方が音楽制作を初歩からやってみる、という(残念ながら)リアルタイム視聴者が俺だけしかいないような配信があったので、音楽の基礎(についての知識は持っていた)を教えてあげたお返しのような形で、「pythonでこういうことがしたくてこういうライブラリがあるのはわかった。経験はHTML+CSS(変数導入前、Bootstrapなんてなかった)のみ。どうしたらよいか」という質問をしたら、「progateは簡単すぎると思うのでPaizaが丁度いいのではないか」というアドバイスを頂き、比較もせずに即登録したのだが結果的にはこれがドンピシャだった。
最近流行りの、環境構築不要で講座の内容を書いて覚えるタイプのサイト。
無料で入門講座の序盤を受けていたらふと目に入ったのが、「対象者:これからプログラミングを学びたい方。HTMLがどのようなものかを知っている方。」でYoutuber先生のオススメ完璧か?と思った。そして実際に完璧だった。
基本的に1講座3分+演習1~2問+やりたければ問題集たくさんという形式なのだが、これが簡単すぎることなく難しすぎることもなく、俺の知識レベルにベストマッチだった。基本的に毎回何か書くことになるので、変数とは~みたいな解説だけで終わる回がほぼ無いのも飽きなくてよい。
Python入門(と言ってはいるがまだこれだけで発展編はない)の見出しは「プログラミングとは」「条件分岐・比較演算子」「ループ処理」「リスト」「辞書」「多次元リスト」「関数」「クラス」「クラス発展」「例外処理」に各5~8講座*3分+演習、という感じ。クラス発展の途中で行けそうだと思ったのでドロップアウトして実製作に移った。実際関数まで理解していれば、この程度の小さなツールには十分だった(もしかしたらクラスを使えば多少楽になった場面はあったかもしれないけど)。
また、これは書いてる今気づいたことだが、上のコースで学んだことで、実際に役立たなかったものはほとんどなかった(強いて挙げれば辞書くらい?使えてないだけかも)。このこともコース構成の優秀さを示している。
ここまででだいたい2週間くらい。
もともとこのサービスは知っていたのと、谷合先生が実際に使っていたように、便利そうなライブラリのcshogiが主にcolab(jupyter)上で動かすことを意図しているようだったので、まずここから入った。最初はcshogiが列挙してくれる特定局面での合法手をリストに入れて、そのリストの項目数=その局面での合法手の数を出力することから始めた。これは本当に簡単にできて興奮した。
学習と好きなことが直結してると、こんなサンプルコードみたいな簡単なことで喜べるのでコストパフォーマンスがよい。
cshogiのチュートリアルで紹介されているレサ改というAIがどうもmultipv(有望な候補手を2手以上挙げる)に対応してないらしく、強さ的な問題でいずれ手を出すつもりだった予定を繰り上げてやねうら王との連携を試みる。
makeって何?あー、もりかしてMakefileが無いと動かない?(これを書いている今もこんな理解である)みたいな人間でもなんとかやねうら王をビルド?することはできた。レサ改をcshogiに読ませる数行のサンプルコードがとても役に立った。今でもあの完成品らしき拡張子が無いファイルがなんなのか分かってない。(なお、評価関数nn.binが無いと怒られたのでどこのご家庭にもある水匠4のそれをぶち込んだら動いた。評価関数とやねうら王の分担は今もって理解があやふや)(また、途中でAyane[やねうらお氏謹製ライブラリ]も使おうとしたがcolab上では上手く動かす方法が分からなかった)
一応これでcshogiで局面の最善手と次善手およびそれらの評価値を呼び出せるようになったのだが、単にdebugでずらずらと余計なものまで出力するのではなく、重要な指し手周りのinfoだけ出力するようにしようとしたが、上手いやり方がわからず、結局こうなった。
sys.stdout = open('out.txt', 'a') engine.go(listener=print)
ここは絶対もっとマシなやり方があるはずなので、識者の教えを請いたい。
Colab上でまあまあ目処がついたので、この辺りでPythonの環境を作った。ここまでそれをやっていなかった理由は、「おま環」トラブルの可能性をなるだけ遠ざけておきたかったからである。環境が悪いのか俺が悪いのか分からない、というのは初心者にとって限りなきストレスである。あーネットが繋がらなくてルーターの設定や接続とか支払いとか文字通り部屋をひっくり返しながら調べてたら実はフレッツ自体が落ちてた件を思い出してイライラしてきた。cshogiはJupyter上で動かすことを意図しているようなので、それで動かなければ自分の書き方が間違っているのだとほぼ確実にわかる。
まあこの辺りはいろんなサイト見ながら仮想化などしつつ普通に。仮想化が何か分かってないんですけど。
これまでColab上で書いてきたものは多少の書き換えで動いたので、ローカルにJupyter notebookをインストールして、数字の計算とグラフ化を試みる。
ちなみにこの時点で得られているデータはこんな感じ。
go info depth 1 seldepth 1 score cp -47 multipv 1 nodes 483 nps 241500 time 2 pv 3c3d info depth 1 seldepth 1 score cp -86 multipv 2 nodes 483 nps 241500 time 2 pv 4a3b info depth 2 seldepth 2 score cp -53 multipv 1 nodes 847 nps 423500 time 2 pv 3c3d 9g9f info depth 2 seldepth 2 score cp -68 multipv 2 nodes 847 nps 423500 time 2 pv 8c8d 7g7f info depth 10 seldepth 17 score cp -78 multipv 1 nodes 100163 nps 1963980 time 51 pv 8c8d 2f2e 4a3b 7g7f 3c3d 2e2d 2c2d 2h2d 8d8e 6i7h 8e8f 8g8f info depth 10 seldepth 17 score cp -111 multipv 2 nodes 100163 nps 1963980 time 51 pv 3c3d 7g7f bestmove 8c8d ponder 2f2e go info depth 1 seldepth 1 score cp 117 multipv 1 nodes 206 nps 206000 time 1 pv 2f2e info depth 1 seldepth 1 score cp 78 multipv 2 nodes 206 nps 206000 time 1 pv 7g7f ...
今回の小目標は、goで区切られた中から下から2行目と3行目のcpほにゃららを取得していい感じのリストにする、というものだ。この辺りは正規表現でなんとかなるだろうと見通しを立てたが、実際そうなった。
ただ、後手が見たときの評価値が後手目線なので、それだけにマイナスをかけるのはどうするか(そうしなければ、先手+3000点の次が「後手から見て」-2900点だったりして綺麗にグラフにならないのだ)を調べるのに結構時間が掛かった。
また、詰み周りでまたプラスマイナスやカンストの絡む計算をしたくないのもあり、数値にNaNを入れてグラフ表記を省略することにしたのだが、そうするとnumpyの関係で整数(とNaN)しか扱わないのに浮動小数点で計算しなければいけなくなって若干気持ち悪かったり。まあ動くのでヨシ!
この時点で、ローカルにKIFファイルを保存し、pyファイルでcshogiと水匠を動かし、Jupiter notebookを開き評価値グラフと手の広さのグラフを重ねて表示する、というそれなりのものは出来上がった。
簡単に言えばpyファイルで1手10万局面(森内チャンネルに出てたHEROZの方が使ってた数字をそのまま使っているので特に意味は無い)探索させ、最善手と次善手についての生の評価データを吐き出させ、ipynbでそれを整形し、グラフ化している。
基本的に全部VSCode上でできるので、慣れれば計算時間も含めて10数秒で結果が出るのだが、このワークフローはいかにも美しくない。
なので、Flaskという簡単らしいフレームワークを使ってローカルでWebアプリとして使えるようにしようと思った。inputとoutputをどうにかするだけだから余裕やろ。
Google colabを触り始めてからここまで1日。圧倒的成長!
Paizaラーニング再び。後半ではデータベースとか本格的な話もあるようなのだが、txtに書き込む一行掲示板を作るまでの前半部を高速で履修(演習は全部飛ばした)。なるほどー、こうやってやりとりするのね、と最低限は完全に理解した。
Jupyter向けのコードを普通のPythonに直してあっちで数字を出してこっちでそれを受けて元に戻して……とかやってると循環参照か何かで怒られることに。その対策に細かく部分を分けて関数にしたのだが、その場合ってもしかしてdefの内部しか読まれない?(共通部分も読まれると思ってた)(いや、共通部分は読まれるけど他のdef内が見えないのか?何も分からん)なるほど。こうなると関数の内部から上に戻るためにクラスとか欲しくなるのかなーという感想。
最終的にWebに公開しようとこの時点では思ってたので、txtに一旦出力するのが安全性的にどうかとか考えてたのだが、テキストの読み取り周りでハマる。結局抜け出せず諦めた。
以降は、HTMLにダブルクオートが抜けてるのに一時間気づかないとか、FlaskのXSS対策の対策をするとか、ファイルの書き込み設定をミスって2万手くらい蓄積されて評価値グラフが大変なことになったが、原因に気づかずひたすらグラフ生成部を調べ続けるなど、非本質的な問題にかかずらっていたので書くことは特にない。
なので、最初にgitignoreしてなかったせいで1万ファイルくらい上げそうになったけど、それ以外は特に問題も無く。中間報告からここまで2日ほど。結局1ヶ月かけずにプログラミングをそれなりに身につけることが出来た。「プログラムを覚えたければ作りたいものを見つければいい」というのは本当だな、と改めて思った。
https://anond.hatelabo.jp/20220107060727
どれくらい書けるようになったのか、を見たい方は主にvalue_output.py(将棋AIに思考させてデータを取り出す)とgraph.py(データを整形してグラフを書き出す)を見ていただければいいかと思います。
最初にPaizaを教えてくださったYoutuberの方、cshogiを初心者でも使いやすいように作って展示してくださったTadaoYamaoka様、水匠開発者のたややん様、水匠含めこんにちの将棋AIの基盤を作ってくださったやねうらお様、cshogiを通して利用したpython-shogiのKIFパーサーを書いてくださったTasuku SUENAGA様に、厚く御礼申し上げます。
最初に結論から書くと、「データをサーバーとやりとりする掲示板のような機能の実装に1年かかっても取り組めていない」
個人的な目標があり、非IT系だが、webサイト作りをやってる。
しかし、なんとかVue.jsで静的サイトで動きを出したり、BootStrapでタブを作ったりすることはできる。
Firebaseで静的サイトや、AWSでS3にサイトhtmlを置いて公開することもできる。
掲示板の機能を持たせるには、投稿データを保存したり表示したりする必要がある。
そうなると、さーばーから情報を読み出すべきだが、そもそもサーバーに情報をどうやったらためて置けるかがわからない。
Railsの場合はセキュリティーが怖いからやめておきたい、できればクラウドサーバーの機能をそのまま使いたい。
クラウドサーバーにデータを投稿したりクラウドサーバーから読み出す機能がもっと簡単にならないかなあ。
Udemyや本を読んでも、なかなかできるようにならないです。みなさんどうしてます?
https://anond.hatelabo.jp/20210617075257
上がってるような基本(元増田に上がってるやつの倍ぐらい)が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク&デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい?
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek(人間性)とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、(基礎的な部分を)調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術(①⑤⑥は他の言語やフレームワークで代替可能)が身に付いていなければまともな企業に就職することは難しい(もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが)。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。(DAOを丸ごと書き換える羽目になる)
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法(XSS・SQLインジェクション・CSRFなど)が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
音楽ジャーナリスト、YOASOBIについて「このビートの単調さと音色・音圧のショボさが世間で許容されてるのはちょっと信じたがたい」
https://togetter.com/li/1654398
これ、タイトルだけ見て「今更音圧……?まーでもそんなこと思う人もいてもおかしくはないな」と思ってスルーしてた。
で、さっきこの増田を見かけたので答えてあげるべく元ネタも読んでみた。
音楽評論家に聞きたいんだけど「ショボい音色・音圧」ってなに?
https://anond.hatelabo.jp/20210119190456
アルバム通してちゃんと聴いた。この気恥ずかしさは嫌いじゃないんだけど、このビートの単調さと音色・音圧のショボさが世間で許容されてるのはちょっと信じたがたい。少なくとも家のスピーカーで聴く音楽じゃないですね
ええ……。元記事が何を言っているかはてなの人に分かりやすい話題で言うと「Webサイトを全部眺めてみた。この気恥ずかしさは嫌いじゃないんだけど、このデザインパターンの単調さとFlashも使っていないサイトが世間で許容されてるのはちょっと信じたがたい。少なくともFullHDで開くサイトじゃないですね」と2021年に言ってるような感じか。
ビートの単調さがダメって、お前2020ビルボード1位の前で同じこと言えんの?
https://www.youtube.com/watch?v=fHI8X4OXluQ
「音色がショボい」に関しては、字面だけ見たらまあ同意するよ。でもそれが「プリセット批判」in2021となれば話は別だ。
増田に音色がショボいがどういうことかを説明すると、一般的には「生録ではなく打ち込みの音色が安っぽい」というところを意味すると思う。昔のMIDIとかカラオケとか、あるいはスーパーでかかってるJ-POPのインストとか、音色がなんか「パソコンで打ち込みました!」「生の音じゃありません!」って感じしない?逆に最近のピアノだけで数万円数十ギガバイトするような音源だと、ピアノの鍵盤から指が離れるノイズまで拾っていたり、弦と弦の共鳴まで再現していたりして、生の演奏と区別がつかない。
そういう意味でYOASOBIの音色がショボいことに異論は無い。まあ、後ろの音をカットして極端に打ち込みっぽくしてる夜に駆けるのピアノに代表的なように、それはあえてやってることなのは明らかであるので、本人達はショボいの一言で済まされると嫌だろうけど。
し・か・し!この音楽評論家は「音色がショボい」をそういう意味では使っていない。「シンセサイザーのプリセットをそのまま使っている」ことをもってショボいと言っている。まあそれはいいよ。別に広辞苑に音がショボいの定義が載ってるわけでもないし。
し・か・し!2021年にそのことをもってアーティストを批判しているとなると正気か?という感じだ。さっきの例に載せきれなかったが、これは「bootstrap.min.cssを読み込んでる!手抜きだ!このサイトはショボい!」と言っているに等しい。いや、使い方次第だし、つーかそれ今時普通だし……という。
シンセサイザーに出荷時に登録されたプリセットそのまま使うのは手抜きであると考える人がいる(というかいた、絶滅危惧種)のはまあわかりますよ。でもね、2021年に「プリセットしか使わない曲が世間で許容されているのは信じがたい」とか音楽評論家が言っちゃうのは死ぬほど恥ずかしいことなのでやめた方がいいと思います(「プリセット~が許容されるのは嘆かわしい」というのだったら賛同はしないが理解は出来る)。
まずあなたは打ち込みJ-POPにそこそこ詳しい音楽評論家顔で登場していますけど、小室哲哉ってひと知ってます?ちょっとマイナーかな?多分知らないと思うのでただのリスナーの僕が評論家先生に説明してあげますが、「プリセットしか使わないでJ-POPで天下を取った男」です。小室はプリセットをほとんど弄りません。そのことを彼はインタビューで度々悪びれもせず語ってきました。
https://www.youtube.com/watch?v=LgBxze0ye94
これの30秒過ぎから、クラブ系の曲を作ったことがある人だったらフフッとなると思う。なぜならここで、Sylenth1というクラブ系で1番人気のシンセサイザーの、起動して一番最初に鳴らせるプリセットがそのまま使われているからです。他に90年代当時の曲でも、あのピアノはどのシンセの何番のプリセット、とか結構バレてる。本人も隠してないし。
と、いうわけで20年以上前にはもうプリセットまんま使いで天下を取った人がいた訳なんですよね。評論家さんはご存知なかったみたいなので今日は小室哲哉の名前だけでも覚えて帰ってくださいね。
で、別にプリセットまんま使いは新しいことでもないのだが、むしろ最近のトレンドだったりもする。海外アーティストのトラック(要するにソースコード)見てみ、やつらNexus(めっちゃいい音のプリセットが大量に入ってるシンセ、bootstrapのuiパーツみたいなもん)しか使ってねーぞ。
まーそんな感じなんで、2021年にプリセット批判は正直かなり何も知らないのがバレて共感性羞恥でキツいっす正直。
に、加えて音圧!2021年に音圧がない=悪いとかいう論をプロがぶつとは夢にも思わなかった。音圧戦争ってFlashのサポート終了より前に終了したぞ。それもまさかご存知ない……?
そもそも音圧が何か分からない、あるいは最近の音圧事情が分からない方に説明します。CDとかの場合、入れられる最大音量ってデータ的に決まってるんですよね。弁当箱の容量と思ってください。で、人間って大きい音の方がいい音に錯覚してしまうんですよね。弁当のカロリーが高いほどジャンクに旨く感じてしまうと思ってください。そうなると弁当箱にいかにカロリーを詰め込むかという戦争が始まりますね。
音圧が高い曲の例
https://www.youtube.com/watch?v=e-IWRmpefzE
このあたりの話は「音圧戦争」とか「海苔波形」とかでググってもらえればいいんですけど、決まった容量の弁当箱に詰め込めるだけ詰め込むと色々犠牲になるように、音楽でも音質が犠牲になっていました。
で、それを技術で解決したのがYoutubeとかSpotifyとかですね。彼らは音圧が高い曲の音量を下げて、他の曲との音量差を少なくしました。揚げ物使った弁当は弁当箱のサイズを強制的に2/3にするイメージですね。そうして消費者は錯覚に騙されず本当に美味しい弁当を選ぶことができるようになりました。めでたしめでたし。というのが去年一昨年あたりまでのあらすじなんですけど、評論家さんご存じない……?で、去年あたりはその音量を下げられる中でいかに上げ底とかで消費者を錯覚させていくかとか、あるいは消費者の側で「ここ10年くらい揚げ物ばっかで飽きたから煮物とか逆に今新しい気がするわ」とかムーブメントが出てきてるのも、これもご存じない……?たとえば最近Youtubeとかで80年代Citypopとか流行ってるのはその流れもあります。
総評:あの音楽評論家の言っていることは無茶苦茶なので理解できないのが正しい。増田は悪くない。
(2021/2/7追記)書きました anond:20210207093448
もうすぐ年末年始休暇も折り返しに差し掛かるので軽く振り返ってみる。
作っていたウェブアプリをJavascriptからTypeScriptに移行した。
自分はこのウェブアプリに関して『自分の死んだ後も変わらず動作し続け、後世の奇特な人が気が向いたらメンテ出来る』ことを目指しているので、できるだけフレームワークなどは利用せずpureなJavascriptで実装していた。最初はjqueryを使っていたが廃止し、bootstrapも使っていたが廃止し、Vue.jsで作り直したものも本番投入せず廃棄した。他のウェブアプリで新しい技術を試すことはあっても、このウェブアプリだけは徹底的に保守的なスタンスを貫いてきた。でもここ数年の流れから言って、TypeScriptなら将来的にも大丈夫かな、と思えて来たので、満を持してのTypeScript化。
イベントの実行順序などで多少苦戦したものの、それ以外は大きな問題もなくTypescriptで再構築することができた。
あーやっぱり型があると良いね。画面制御と描画処理が今まで1つのモジュールでやっててそれを何とか解消したかったんだけど、型が入ることでそのリファクタリングを安全に行うことができた。描画周りが分離できたんで、そこだけvueなりreactなりに再挑戦するのもアリかもしれない。どっぷりフレームワークに浸かるのは避けたいけど、部分導入だけなら後で捨てるのも容易になる。捨てるのが簡単ならちょっとくらい試しても良いかもしれない。
Google App Engineで動作している自分のサイトをPythonからGoに移行した。
サーバーサイドではほとんど何もやっていないので別にPythonで不便はなかったんだけど、インスタンスの起動がGoの方が早いらしいので、Goに移行することにした。起動が早ければ待機させるインスタンスの数を抑えられるので、費用の低減を図れる。Goで作り直すと言ってもほとんどが静的なhtml。手作りbootstrapからhugoに移行して、サーバーじゃないとできない最低限の処理をGoで書き直し。素人感丸出しのサイトが、hugoのテーマのお陰でそれなりに見栄えのするものになった。
問題は、実装可能性が乏しいデザインが多くてエンジニアからのフィードバックが膨大に必要だとか、画面サイズや内容の可変への考慮が浅いとか、そういう所では。
単にB2Bな業務システムなら、フォトショ使うまでもなく、ポンチ絵だけレイアウトしてあとはbootstrapなりbulmaなりmaterial-uiなりでいいだろって話ならまぁわかる。
…が、お前そこまで有能でもないよね。書いてる内容で分かる。他人disるほどデザインわかってる?
まぁこう言われると「俺はエンジニアであってデザイナーじゃないから」って言うんだろうけど、デザイナーも「私はデザイナーなのでHTML/CSSは私の仕事じゃないです」って思ってんだよ。
DTPからweb移行でももうちっとあるでしょなAdobe知識がないうえ、ワイヤー作ってくださいも最初通じずなんでもいいからデザイン出してって出てきたものに沿ってざっくりbootstrapで手抜きして組んだら
てめえPC/SPでデザインよこせつうたのに出てないし、aiのと異なる口頭での文字サイズがもっと大きい小さいのがいいとか舐めてんの?そう言うこだわりあるなら自分でコーディングするか人にちゃんと指示しれや
つかaiから画像の切り出しアセット関連の機能も知らず解像度てかサイズたりてねえっての
で、もらったデータはやつしか持ってないモリサワフォントでOLかけたのと元のとでLPなんこもつくるそれ×2とかで、全部同じファイルのアートボードに入れてよとかデータ作りからコケてるからデータもらった後にこう作って欲しかったとかできないじゃん
そこまで指示されるデザイナーってなに?素人?自称webデザ?つかデータ作るときに聞けよ
って期待してんのがクソか?ハァー
ジョー氏にはサイトが機能してればそんな細えこたあいいんだよって言われてるし締め切りも迫ってるから目先の制作をあげるの優先で本人はコーディング丸投げして暇になったからなんか仕事ある?って聞いてるんだーとか聞こえてんだよクソが
って言う愚痴です