  |
はてなキーワード: デザインパターンとは
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（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
大学の専門課程ではじめてプログラミングに触れるケースを想定する。
情報科学専攻で半年か一年かけてやる程度の内容だが、他のほとんどの科目でもそうであるように、要領の良い奴なら数週間でマスターできる。
実際、世の中にはこのレベルの奴なんか珍しくもなくいる一方、Pythonチュートリアルレベルの文献を数ヶ月かけても前半数章すら読めないような奴もいて、そういう奴が「プログラマになりたい」とか言ってる。本当に社会の迷惑。やめてくれ
お前「GoFのデザインパターンが重要であるかのように言うやつムカつく！」って、もう一年ぐらい怒ってるんだな
低レベルから努力してやっと平均かその一段下くらいになっただけの雑魚が「自分は上級者」だと勘違いして偉そうにしているケースが多くて、嫌になる。
たとえば、C言語のポインタが難しいとよく言われる。まあ、中学生や高校生がはじめて学ぶならともかく、あんなもの別に難しくはない（実際のソフトウェアでポインタを適切に使うことは難しい）。
実際、ポインタに躓かなかった人なんかたくさんいて、そういう人の一部はより高度なことをどんどんやっている。一方、ポインタに躓いて努力してやっと最低限のレベルに達したような人が、声を大にして「プログラマになるなら、ポインタくらい理解しないとな」とか言ってる。
プログラミングのセンスのある奴はすぐ見抜けることだが、アレには何の重要性も無い。だが、頭の悪い奴は、あの程度でも苦労しないと覚えられないから、重要だと思ってしまうらしい。これはギャンブルや宗教にハマる心理と同じである。つまり、時間や労力をかけたのだから、その対象にそれに見合う価値があって欲しいと思うわけだ。
頭が悪いと、こういう意味で物事を客観的に見られなくなる。学歴コンプレックスになると、一生そのことを引き摺って、何に関しても学歴と絡めて論じたくなるようなものだ。
音楽ジャーナリスト、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
書くより読むほうが上達する。
社内の上手い奴が書いているコードを読め。
社内の下手な奴が書いているコードを読め。
上達しないって言ってる連中はコードのパターン、イディオムを知らない。
最終系のコードのイメージが無いからコードに方向付けが出来ないし、その場その場で取っ散らかった実装になる。
デザインパターンだけ知ってたって使ってる言語で実現する方法を知らなきゃ活用できない。
単体テストは単体テストを書きやすいコード、書きやすくするための工夫を知らないと書けない。
適切なエラーハンドリングをするなら例外とは何か、ライブラリではどういう例外をどういうときに投げているか知らなければ正しくハンドルできない。
念願叶ってプログラマとして生計を立てるようになって、はや8ヶ月。
アラフォーでの思い切ったキャリアチェンジを後悔したことはないし、毎日楽しいことの連続だけれど、俺はいまプログラマとしての伸び悩みを猛烈に実感している。
具体的には、オブジェクト指向とかデザインパターンとか単体・結合テストとか適切なエラーハンドリングとかアルゴリズムとか、納品物としてプログラムに一定の品質を担保するスキルが圧倒的に不足している気がする。
一応日々勉強はしているものの、納期に追われているとどうしても手癖でコードを書くようになってしまうし、社内にコードレビューの文化がまだ根付いていないので添削してもらう機会もなく、なかなかスキルが身に付いていかない。
プログラマのみんなはどこでそういった知識を得て、どうコードに活かすのだろう？
とにかく毎日書きまくって手癖を克服あるいはブラッシュアップして、あとはコードレビューしてもらえるように社内環境を整えるしかないんだろうか。
本いる？
まずさあ、〇〇を作りたい！って情熱が最初にあればあとはどうとでもなるよね。
ゲームが作りたかったからYaneScriptでゲーム作って喜んで満足してたよ。
んでYaneScriptはC言語に近かったからそのままスムーズにCも覚えて、
そのあとJava覚えてC++覚えていって、オブジェクト指向とかデザインパターンとか覚えていったよ。
本に頼らないとダメだなんてプログラミング向いてないんじゃない？ｗ
というのは半分冗談で、ある程度覚えてからは普通に本で勉強したけどね。
でも最初はなんの言語でもいいからとにかくモノを作って動かして楽しー！ってやればいいんじゃないですかね。
そういうのがない人も別にやめろとは思ってなくて、必要ならスクールに通えばいいんじゃねーの。
あー、確かに僕はオブジェクト指向をちゃんと理解できてないです。
データの扱いが汚いせいでぐちゃぐちゃになってるのだと思ってました。
最初は一生懸命考えてクラスを作るのですが、だんだん最初のルールでは扱えなくなってきて、妥協に妥協を重ねてなんでもできるクラスになっていってしまいます。
プロダクト全体のデザインパターン（アーキテクチャ系）を決めておくのは必須だろうな
時々、Managerクラスを乱発して見るに堪えないプロジェクトを見ることもあるけどwww
抽象化し過ぎたというのは経験上あまりないかな。仮にやり過ぎというのがあったとしても困ることはほとんどない。
共通化に関してはむしろ依存性が高まる可能性もあるので、やるならシンプルな処理が良いだろうね。
使い道含めて理解してる？
要するに前のプロジェクトはパワーコーディングで作っていった結果、収拾できなくなってしまったんでしょう？
抽象化というのはそのまんま情報の簡略化であり、情報を簡略化するには綺麗なコードじゃないと無理なんだよ。
綺麗なコードは各々のオブジェクトが持つべき役割・持つべきではない役割が明確化されており、綺麗なコードというのはコードコメントがなくても他者が理解できるようになっている。コード自体が処理の説明がなされているんだよ。
もう一つ、あなたのプロジェクト構成はちゃんとレイヤー化されている？
新しいクラスファイルを配置する時、明確なルールが作られている？
とはいえ、誰しもが最初から全てを理解しているわけじゃない。みんなあなたのように「やらかして」反省して、同じ徹を踏まないように次のコードで反映させていくのだから。
わからない。
[追記]
ちょっとわかってきた気がする。
