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

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

2022-05-22

anond:20220522163908

新しい言語にはたいてい新しいアイディアが含まれてる。そういうのを知るのは楽しい目からうろこが落ちるような経験結構あった。おれも PHPer だったけど、以前、.NETLINQ を学んだときは楽しかった。

まあ PHP はその「新しいアイディア」をどん欲に取り入れ続けている言語から、けっこうそれだけで満足してしま気持ちは解る。でも「今の自分知識だけで、たいていのものは作れるからなあ」と思ってしまうと、たぶん勿体ない。あなたが将来、未知のプラクティスデザインパターンアルゴリズム発明しないと断言できないのだから

PHPer ならマニュアルの例文で散々お世話になっている「干し草の山」と「針」のたとえ話で言うと、次のような感じ。

https://kenbi.ti-da.net/e3637076.html

アインシュタインはあるとき

博士わたしたちその他大勢との違いはなんですか?」という質問を受け、

こう答えました。

「たとえば、干し草の山から針を探さなければならないとします。

ほとんどの方はたぶん、針が1本見つかるまで干し草の中を探すでしょう。

私は、針が全部見つかるまで探し続けると思います。」

PHP ですでに作られたものは膨大なので、そのメンテナンスも今後何十年は無くならない。仕事にあぶれることはないと思う。

2022-02-09

その辺の技術者知識で負けないくらいのふるすたっくえんじにあになりたい

機械工学大学で学んだ。機械系4力学さわりだけなら大体やったがもう忘れている。

・切削加工はけがきフライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ3Dプリンタでなんでも作れるらしいが、3Dプリンタは触ったことがない。

CAD大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。

シミュレータANSYSマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。

電気工学はだいぶ勉強不足。簡単回路図チップ製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。

化学系は全くの無知大学受験で知識は止まっている。物性物理的なところも無知

数値計算PythonMatlabちょっとできる程度。ライブラリを使った行列計算簡単ニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分常微分方程式を調べて思い出せばできる程度。測度論とか特殊積分かいわゆる大学数学的な道具が必要になる解析はできない。

競技プログラミングちょっとかじったがやめてしまった。むずかしすぎた。

機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定1級落ちた。

バックエンドSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった&謎のSegmentation Faultで苦手意識を残したまま。Go?Rust?なにそれおいしそうだね。

クラウドAWSマニュアル通りに使っている程度。1から設計なんてできない。なのでAWSソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。

ネットワーク系とかセキュリティ系は全く勉強不足。応用情報ギリギリ合格できる程度の知識しかない。わかるようにはなりたい。

フロントエンドFlutter勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離ありすぎてよくわからない。javascriptはjQuery一強時代ちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript?なにそれおいしそうだね。

ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。

全部中途半端だな、、、

2022-02-03

[]2022年1月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

278あとで/1848users セガjavascriptぷよぷよを作るプログラミング講座を出しているが、とても良いプログラミングの教材になっている「写経はとても大事」 | Togetter

238あとで/1666users ジャズコード進行原理 - アラクー Arakur

228あとで/1260users ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive

220あとで/1885users Adobe製品と同じような事をフリーソフトでやりたい場合対応表がすごく使える→他にも高機能フリーソフトが集まる | Togetter

211あとで/1407users 「Visual Studio」の中の人が作ったプログラマー向け十徳ナイフ「DevToys」/今までググって探していたツールがひとまとめに | 窓の杜

210あとで/3113users ゲーム勝敗かんしゃくを起こす子どもにできることは大人げない大人になること|フィンランドワークショップomena|note

201あとで/1188users 総務省「誰でも使える統計オープンデータ無料オンライン講座スタート | ITMedia

198あとで/960users プログラムメモリをどう使うかを理解する(1) | rita | Zenn

196あとで/1262users 仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話田辺めぐみnote

189あとで/973users フロントエンドデザインパターン | Shinya Fujino | Zenn

187あとで/1551users 英語面接で5歳児みたいなことしか言えないからカッとなってWebサービス作った【個人開発】 - Qiita

187あとで/1563users TOEIC満点ホルダーがやっているおすすめ英語学習法(2022年版)|Shinnote

177あとで/1554users 207で1年間磨き続けた1on1フォーマットを公開します|207株式会社note

171あとで/1530users エンジニアの"有害な振る舞い"への対処法 - Qiita

170あとで/1316users 顧客との打ち合わせが上手い人がやっていること|いまにし|note

165あとで/1551users 「この会社は詰んでます。潰れました」で気づいた“恥ずかしさ” DeNA南場智子氏がエンジニアから学んだこと | logmi Tech

158あとで/1342users 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎|note

153あとで/1343users 強いエンジニアになるために英語必要と聞いたので4ヶ月でTOEICスコア400→900まで上げた話 - Qiita

148あとで/1190users なぜ40歳を越えると「やる気」が出ないのか? 「中年危機」を乗り越えるためのエンジンの回し方 | 野水克也, 萩原雅裕 | logmi Biz

148あとで/955users ITエンジニア投票した「ITエンジニア本大賞2022」ベスト10発表。「シェルワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など | Publickey

142あとで/690users JavaScriptを遊び尽くす究極のWebサービスツールを厳選して大公開! - paiza開発日誌

138あとで/891users そこまで努力しないで生活ちょっと改善する100の方法 | 英紙元旦に紹介 | COURRIER

137あとで/1237users 問題職員の正しい辞めさせ方 1/10 | anond.hatelabo.jp

136あとで/635users フロントエンドを集中的に学習できる究極の無料リソースを厳選してみた! - paiza開発日誌

133あとで/768users ミーティングファシリテーション入門 / Introduction To Meeting And Facilitation | ストックマーク株式会社 iwashi | SpeakerDeck

126あとで/1056users Future社員が使っているWindows便利ツール新人さん向け) | フューチャー技術ブログ

126あとで/802users 『データ分析のためのSQL勉強会資料公開|高橋 光|note

126あとで/859users エンジニアを始めてから便利だったツールまとめ | nakaatsu | Zenn

125あとで/757users 2022年におけるフロントエンド開発のベースライン - LINE ENGINEERING

123あとで/1202users 50歳になってようやく気付いた、人生重要なことと、後悔したこと。 | fujipon | Books & Apps

123あとで/1055users 【必読】総務省直伝のExcelマニュアル目から鱗が落ちるものだった | Togetter

ジャズコード進行解説したブログが2位になった。はてブでこんなページを目にできようとはとブクマカ驚愕

COURRIERの「そこまで努力しないで生活ちょっと改善する100の方法」はペイウォールの向こうに行ったが原文は読める。 https://www.theguardian.com/lifeandstyle/2022/jan/01/marginal-gains-100-ways-to-improve-your-life-without-really-trying

2021-12-04

anond:20211203154548

クリーンアーキテクチャとかドメイン駆動設計とかそういう思想のものは読んでも分からない。デザインパターンも読んだことあるけど理解できたことない。底辺プログラマには高尚すぎて頭に入らない。

難しいことはいいから、今俺が悩んでいることを具体的に解決してくれる本が欲しい。答えが欲しい。難しいことは分からない。お前が非エンジニアなのになぜそんなに詳しいのかも分からない。

世界は俺が理解できる世界ではないのかもしれない。バグが埋め込まれている。俺か世界のどちらかに

2021-12-03

anond:20211203140112

アーキテクチャの本もあるじゃん

非エンジニアの身からすると、クリーンアーキテクチャとかドメイン駆動設計とか古いやつだとMVCとかそういうデザインパターンの本も結構色々あると思うけどそういうので不足するようなもんなん?

というかアーキテクチャに関しても抽象化すれば

・どこに着目して分割するか

疎結合と密結合でどの部分を分離してどの部分をどちら方向に依存させるか

みたいな話だと思うから、そういうのを意識すればブログとかでも情報十分拾える気がする。

あくまでも非エンジニア目線だけど。

2021-06-17

CTOだけど、一ヶ月Web就職レビューしてみた。

https://anond.hatelabo.jp/20210617075257

0. 温度感

基本的現在では、バックエンドフロントエンド運用保守全てができないエンジニア価値は無い。

経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。

典型的はてなー意識の高さ。

上がってるような基本(元増田に上がってるやつの倍ぐらい)が全部立ち上げからできて

2〜3個プロジェクト経験したらテックリード素養が既に身についてそう。

まり、ただのエンジニアにはそこまで要求されない。

プロジェクト的にもどっちかが弱いと

Rails/DjangojQuery+Bootstrapみたいな構成

Amplify/FirebaseにVue/Reactみたいな構成全然あるので

フロントバックエンドも一旦はどっちかでいい。

面接はなんとか抜けてもらうとして、

チーム開発での最低限の目標としては、

成果物から指導学習コストレビューコスト技術負債マネジメントコストを引いた分が正になっていれば

ひとまず「チームに居ていい人」と見なされそう。

チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、

一旦は、正の生産性を目指してほしい。

以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、

一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。

1. 言語: PythonJavascript

これだけで一ヶ月経つ気がするが正気か。

似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。

どっちかしかやらないならJavascriptおすすめ。後ででてくる、Flaskは適当Expressかに置き換える

現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。

どちらも、Python2とES2015以前の記法というレガシーネット上に転がってるので参考にしないように注意。

パッケージ管理単体テストタスクランナー

この辺は6のフロントフレームワークと同時にやる。

コードは断片的なサンプルではなく

一貫性があって

・正しい書き方がされた

お手本プロジェクトをなにか(github書籍など)で手に入れて読むべき。

おそらくフレームワークに乗っかっているので並行して進めることになる。

6. フロントエンドフレームワーク: Vue.js

話の流れで先にこっち

現在コーディングのグッドプラクティスデザインパターンフレームワークの形をしている。

なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。

とはいえ最低限としては使い方が分かるところまで。

TypescriptVue.jsも書き方をどこまで取り入れるかが使用者裁量に任されてるし、

開発でVueとReactのどっちを使うかはチーム次第なので、

一旦React+Typescriptガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。

2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。

パッケージとかテストタスクデプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。

2, 4. ツール: gitDocker

バージョン管理コンテナ思想が優れているのは自明なので、これらはツールと見ていい。

そして、後からプロジェクトに入った人がプロジェクト流儀に沿って使う分には難しいことはなさそう。

採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、

そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。

構築できる、ではなく、触れる程度で良さそう。

gitプロジェクト流儀によると書いたが、git-flowイメージ図を理解して運用できるのがよい。

https://qiita.com/KosukeSone/items/514dd24828b485c69a05

3. OS: Linux

これは「パソコンの使い方わかってますか」ぐらいの温度感

ファイルパーミッションユーザープロセスのような基本概念理解する

一冊読めば済むだろうし、概念系はさらっておいてほしい。

grepやfindやxargsなどのコマンドを組み合わせて簡単な処理を自動化する

こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。

sedとか正規表現も。

あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。

IPアドレスを調べたり、SSHリモートマシンログインする

地味にSSHログインした先の環境だと、vimが主要なテキストエディタになるので

vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。

ファイル開いて入力モードに切り替えて書き込んで保存して終了

チュートリアルする。拡張とかはいらない。

細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。

5. サーバーフレームワーク: Flask

フレームワークを覚えること自体重要なのではなく、Web開発の基本を習得することが重要

これが意図なら

HTTPルーティングデータベースSQL認証セッション管理などは当然すべて覚える。

この辺の機能を持った小規模Webアプリを作ってHerokuデプロイすれば一旦完成とみなしてよさそう。

コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい?

慣れると1日あればいけると思う。

フレームワークもなんでもいい。

軽量である必要もなくて、

Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。

余力があれば複数個触ってみたり、人から勧められたらそっちでも。

最近サーバーレス&NoSQL流行ってるのでFirebaseとかもやればいいと思う。

7. アルゴリズム

コメントリーが荒れててウケる

実務プログラミングで最低限必要アルゴリズム力は

「書いてるコード計算量オーダーを把握していること」

に尽きる。

計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて

O(n^2)やO(n^3)のロジックを書いてしまって

データ量が万〜十万の本番データで遅延するとか

それらに対して分散や非同期処理で解消しようとするとか、

ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為

アルゴリズム不要勢は平気でやるぐらい、両者は溝が深い。

計算量を意識するだけなら、AtCoderABCのC〜D問題辺りが解ければ十分。

8. セキュリティ

有名な脆弱性攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている

(XSS対策自動エスケープなど)

のでアドリブをせずに正しい書き方でやれば良い。

開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、

ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。

最後

開発の勉強のやり方としては、

・正しいコード見本を手に入れること

公式リファレンスを読むこと

エラーメッセージを読むこと(そしてググること)

この辺りの習慣があればやってけんのかな、

その他、チーム開発って面では

アジャイルサムライプロジェクト管理)とか

TeamGeek(人間性)とかインプットしておくと共通言語が増えて嬉しい。

この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、

そしたらやってけるんちゃうーって感じ。

2021-04-25

anond:20210421172633

記事を読んだが俺はオブジェクト指向には反対だね。

IoTとか言って、モノを重視するのは前時代への退行だよ。

デザインパターンとか言って、世の中や人間を型に当てはめたがるのも気に食わないね

これからは心の時代だ。プログラミングも、心を重視すべきなんだ。

2021-04-04

anond:20210404002159

今でもビットフラグって使われているもんなの?

俺は数学アルゴリズムよりも言語のもの知識デザインパターンを正確に組み合わせることが出来るエンジニアの方がいいなと思う。

そこで話通じない方が辛い。

数学アルゴリズム専門性が高い分野の話かなと思うかな。

ゲームAIロボット系とかなら必要だけど。

2021-03-11

プログラミングができる初心者」の基準

大学専門課程ではじめてプログラミングに触れるケースを想定する。

プログラミング歴90分
C言語基本的機能データ型、制御構造関数再帰構造体、ポインタetc)をマスターする
プログラミング歴1日
SOLIDやデザインパターンなどのソフトウェア設計の基本原則独自発見する
プログラミング歴1週間
二分探索やグラフなどの基本的アルゴリズム理解し、実装できる
プログラミング暦2週間
簡単言語処理系算術演算変数制御構造関数を含む)を自作できる

情報科学専攻で半年一年かけてやる程度の内容だが、他のほとんどの科目でもそうであるように、要領の良い奴なら数週間でマスターできる。

実際、世の中にはこのレベルの奴なんか珍しくもなくいる一方、Pythonチュートリアルレベルの文献を数ヶ月かけても前半数章すら読めないような奴もいて、そういう奴が「プログラマになりたい」とか言ってる。本当に社会迷惑。やめてくれ

2021-03-10

anond:20210310110216

お前「GoFデザインパターン重要であるかのように言うやつムカつく!」って、もう一年ぐらい怒ってるんだな

https://anond.hatelabo.jp/20200521094135

もっとからかな

プログラミング界は「自分馬鹿だと自覚できてない奴」が多すぎてうんざりする

レベルから努力してやっと平均かその一段下くらいになっただけの雑魚が「自分上級者」だと勘違いして偉そうにしているケースが多くて、嫌になる。

たとえば、C言語ポインタが難しいとよく言われる。まあ、中学生高校生がはじめて学ぶならともかく、あんもの別に難しくはない(実際のソフトウェアポインタを適切に使うことは難しい)。

実際、ポインタに躓かなかった人なんかたくさんいて、そういう人の一部はより高度なことをどんどんやっている。一方、ポインタに躓いて努力してやっと最低限のレベルに達したような人が、声を大にして「プログラマになるなら、ポインタくらい理解しないとな」とか言ってる。

GoFデザインパターンもそうだ。

プログラミングセンスのある奴はすぐ見抜けることだが、アレには何の重要性も無い。だが、頭の悪い奴は、あの程度でも苦労しないと覚えられないから、重要だと思ってしまうらしい。これはギャンブル宗教にハマる心理と同じである。つまり時間や労力をかけたのだから、その対象にそれに見合う価値があって欲しいと思うわけだ。

頭が悪いと、こういう意味物事客観的に見られなくなる。学歴コンプレックスになると、一生そのことを引き摺って、何に関しても学歴と絡めて論じたくなるようなものだ。

2021-01-20

プリセット・低音圧」批判かいう「今時Flash使ってないサイトとか

音楽ジャーナリスト、YOASOBIについて「このビートの単調さと音色・音圧のショボさが世間で許容されてるのはちょっと信じたがたい」

https://togetter.com/li/1654398

これ、タイトルだけ見て「今更音圧……?まーでもそんなこと思う人もいてもおかしくはないな」と思ってスルーしてた。

で、さっきこの増田を見かけたので答えてあげるべく元ネタも読んでみた。

音楽評論家に聞きたいんだけど「ショボい音色・音圧」ってなに?

https://anond.hatelabo.jp/20210119190456

アルバム通してちゃんと聴いた。この気恥ずかしさは嫌いじゃないんだけど、このビートの単調さと音色・音圧のショボさが世間で許容されてるのはちょっと信じたがたい。少なくとも家のスピーカー聴く音楽じゃないですね

だとしたら音色の選び方にもう少しこだわりはあるでしょう。プリセットしか使わないという強い意志を感じます

ええ……。元記事が何を言っているかはてなの人に分かりやす話題で言うと「Webサイトを全部眺めてみた。この気恥ずかしさは嫌いじゃないんだけど、このデザインパターンの単調さとFlashも使っていないサイト世間で許容されてるのはちょっと信じたがたい。少なくともFullHDで開くサイトじゃないですね」と2021年に言ってるような感じか。

ビートの単調さがダメって、お前2020ビルボード1位の前で同じこと言えんの?

https://www.youtube.com/watch?v=fHI8X4OXluQ

3分間全部一本調子音色の抜き差しも無しやぞ。

音色がショボい」に関しては、字面だけ見たらまあ同意するよ。でもそれが「プリセット批判」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めっちゃいい音のプリセットが大量に入ってるシンセbootstrapuiパーツみたいなもん)しか使ってねーぞ。

まーそんな感じなんで、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

2021-01-13

anond:20210113011527

書くより読むほうが上達する。

上手いコードも下手なコードもとにかく読め。

普段使ってるOSS実装を読め。

普段作ってるアプリ自分が触れていない部分のコードを読め。

社内の上手い奴が書いているコードを読め。

社内の下手な奴が書いているコードを読め。

上達しないって言ってる連中はコードパターンイディオムを知らない。

最終系のコードイメージが無いかコードに方向付けが出来ないし、その場その場で取っ散らかった実装になる。

デザインパターンだけ知ってたって使ってる言語で実現する方法を知らなきゃ活用できない。

単体テスト単体テストを書きやすコード、書きやすくするための工夫を知らないと書けない。

適切なエラーハンドリングをするなら例外とは何か、ライブラリではどういう例外をどういうときに投げているか知らなければ正しくハンドルできない。

かいアルゴリズムより言語機能を熟知していか自分コードを書かずに実現するか考えろ。

からコードを読め。

初心者プログラマをなかなか脱却できない

念願叶ってプログラマとして生計を立てるようになって、はや8ヶ月。

アラフォーでの思い切ったキャリアチェンジを後悔したことはないし、毎日楽しいことの連続だけれど、俺はいプログラマとしての伸び悩みを猛烈に実感している。

具体的には、オブジェクト指向とかデザインパターンとか単体・結合テストとか適切なエラーハンドリングとかアルゴリズムとか、納品物としてプログラム一定品質担保するスキルが圧倒的に不足している気がする。

一応日々勉強はしているものの、納期に追われているとどうしても手癖でコードを書くようになってしまうし、社内にコードレビュー文化がまだ根付いていないので添削してもらう機会もなく、なかなかスキルが身に付いていかない。

プログラマのみんなはどこでそういった知識を得て、どうコードに活かすのだろう?

とにかく毎日書きまくって手癖を克服あるいはブラッシュアップして、あとはコードレビューしてもらえるように社内環境を整えるしかないんだろうか。

2021-01-08

プログラミングスクールに通うくらいなら本を読むな

プログラミングの独学なんてネット情報で十分じゃない?

本いる?

まずさあ、〇〇を作りたい!って情熱最初にあればあとはどうとでもなるよね。

俺は最初は体系的な知識なんていちいち勉強しないで

ゲームが作りたかたからYaneScriptでゲーム作って喜んで満足してたよ。

んでYaneScriptはC言語に近かったからそのままスムーズにCも覚えて、

そのあとJava覚えてC++覚えていって、オブジェクト指向とかデザインパターンとか覚えていったよ。

本に頼らないとダメだなんてプログラミング向いてないんじゃない?w




というのは半分冗談で、ある程度覚えてから普通に本で勉強したけどね。

でも最初はなんの言語でもいいからとにかくモノを作って動かして楽しー!ってやればいいんじゃないですかね。

そういうのがない人も別にやめろとは思ってなくて、必要ならスクールに通えばいいんじゃねーの。

元ネタで挙げられている本は独学では読まなくていいけど、スクール卒業とかちょっと実務経験した後には読めよとは思う。

2020-12-03

anond:20201203133759

そこには完全同意だがそれをしてこの2020年に「クラスインスタンス構造は本当はデザインパターン一種で」と説明するのは誤解を生む不誠実な態度ではないかとも思った

anond:20201203131305

デザインパターン普通意味GoFデザインパターン)以外の意味で使っているのだろうか

こういう人(俺の言うデザインパターンはこういう意味から、的なこと言う人)がいると、まとまる話もまとまらなくなりとても面倒くさい…

anond:20201203094106

クラス自体本来デザインパターンからなあ

今やだれもそんな風に考えないけれども…

2020-10-23

anond:20201023144203

デザインパターンかいう以前に、ソフトウェア設計の基礎の基礎

こういう当たり前のことをなにか特定技術だと思ってるのはセンスが無いんだよ

ビジネスマナーの本読んだけど『朝出社したら挨拶しろ』とは書いてなかった。こういうことはなんて言う本に載ってる?」

とか聞いてるようなもん。プログラミング以前に幼稚園から人生やり直した方がいい。

2020-10-22

デザインパターンって必要だよね?

どこで使うかわからないけど

知らないよりは知ってたほうがいいし

オブジェクト指向理解にも役立つし

使ったことないけど覚えておいた方がいいよね?

anond:20201022212544

うーん、2005年ぐらいか

Scala とか出てきたけど、デザインパターン言語レベルで組み込まれたのは、これぐらいじゃない?JavaJavascript も機能に組み込んだけど。

anond:20201022005749

クラスオブジェクト指向言語機能は何でも出来すぎるという意味goto文に近いと思う。

goto機能的に制限された構造言語構文に進化したように、デザインパターンもっと整理してそのパターンに沿った文法以外では書けない新世オブジェクト指向言語が作られるべきだったと思う。

(実際、イテレータパターンはforeachの文法として言語機能に取り込まれたといって過言ではないだろう)

2020-07-18

anond:20200718045901

あー、確かに僕はオブジェクト指向ちゃん理解できてないです。

データの扱いが汚いせいでぐちゃぐちゃになってるのだと思ってました。

最初一生懸命考えてクラスを作るのですが、だんだん最初ルールでは扱えなくなってきて、妥協妥協を重ねてなんでもできるクラスになっていってしまます

デザインパターンもっと理解しないとダメなんですね。

ログイン ユーザー登録
ようこそ ゲスト さん