「フレームワーク」を含む日記 RSS

はてなキーワード: フレームワークとは

2022-05-25

anond:20220525075720

新しいフレームワークツールAPI言語等々を使いたいってまだマシやで。

大半は、新人の頃に覚えたやり方をいっさい変えたくないって感じやで。

2022-05-22

anond:20220522163908

ワイはC言語だけで年収850万。

くだらんライブラリだのフレームワークだのに人生振り回されることな年収850万。

2022-05-21

かつて人類は1と0を打ち込んでプログラムを書いていたらしい

それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた

多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの?という人たちと、まさにブレークスルー世界が変わるとエキサイトした人たちだろう。

色々あったが、人にも読めるソースアセンブリ言語に変換してくれるCが出来た。

多分このときも単なるアセンブリスーパーセットだろ?なんか意味あんのか?っていう人たちと、やばいレベルプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。

その後Javaが登場してオブジェクト指向が花開いた。

このときも、構造プログラミングに毛が生えた程度のもんだろ?何が嬉しいんだ?という人と、オブジェクト指向なら何でもできる!とエキサイトした人たちで溢れかえったことだろう。

Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。

何が何でも継承カプセル化ポリモーフィズムだとオレオレフレームワーク雨後の筍のごとに開発され結局Strutsに一網打尽にされた。

その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。

もはやこの時点で継承だのポリモーフィズムだのはそれほど重要ものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。

人月神話時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたことき誕生している。DIファクトリリフレクションでなんとでもなることでしょ?何が嬉しいの?と。

その後関数型プログラミング誕生する。

これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ?小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。

マシン語からアセンブリ、CからOOPトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。

抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからいくらいに思考が固まった人、はたまたこ技術なら全て解決できるのだからのものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。

多分20年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。

しか人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議ものだ。

しかに極端な話1と0だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。

オブジェクト指向が最適だった時代は確かにあった。

企業システムにせいぜい20台程度のホストを導入するようなものだった。

今は百や千のオーダーでは聞かない仮想ホストDockerコンテナ複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータアクセスするところではトランザクションに強いJavaというように適材適所住み分け必要がある時代になった。

当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術目的になっている。

継承ポリモーフィズムをする以上はスーパークラスライブラリもなくてはならないが、それも億劫になっているのかもしれない。

今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。

それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代過去のものになったと考えたほうが良いだろう。

関数型プログラミング理解よりも、オブジェクト指向習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。

そういう意味では業界としてだいぶ健全になったようにも思える。

まりにもポエミーで恥ずかしくなったので増田に書くことにした

***追記

何も調べないで主観のみで適当に書き連ねた文章にどうもすごそうな人たちがやたらまじめに反応していて申し訳ない気分でいっぱいになった。

この文章を書くにあたって全く頭は使われておらず、裏もとられておらず、確認もされていないことだけは付け加えておかないとマジレスしてくれた人たちに申し訳ない気持ちがすごいので書いておくことにします。

かつて人類は1と0を打ち込んでプログラムを書いていたらしい

それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた

多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの?という人たちと、まさにブレークスルー世界が変わるとエキサイトした人たちだろう。

色々あったが、人にも読めるソースアセンブリ言語に変換してくれるCが出来た。

多分このときも単なるアセンブリスーパーセットだろ?なんか意味あんのか?っていう人たちと、やばいレベルプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。

その後Javaが登場してオブジェクト指向が花開いた。

このときも、構造プログラミングに毛が生えた程度のもんだろ?何が嬉しいんだ?という人と、オブジェクト指向なら何でもできる!とエキサイトした人たちで溢れかえったことだろう。

Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。

何が何でも継承カプセル化ポリモーフィズムだとオレオレフレームワーク雨後の筍のごとに開発され結局Strutsに一網打尽にされた。

その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。

もはやこの時点で継承だのポリモーフィズムだのはそれほど重要ものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。

人月神話時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたことき誕生している。DIファクトリリフレクションでなんとでもなることでしょ?何が嬉しいの?と。

その後関数型プログラミング誕生する。

これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ?小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。

マシン語からアセンブリ、CからOOPトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。

抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからいくらいに思考が固まった人、はたまたこ技術なら全て解決できるのだからのものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。

多分20年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。

しか人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議ものだ。

しかに極端な話1と0だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。

オブジェクト指向が最適だった時代は確かにあった。

企業システムにせいぜい20台程度のホストを導入するようなものだった。

今は百や千のオーダーでは聞かない仮想ホストDockerコンテナ複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータアクセスするところではトランザクションに強いJavaというように適材適所住み分け必要がある時代になった。

当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術目的になっている。

継承ポリモーフィズムをする以上はスーパークラスライブラリもなくてはならないが、それも億劫になっているのかもしれない。

今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。

それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代過去のものになったと考えたほうが良いだろう。

関数型プログラミング理解よりも、オブジェクト指向習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。

そういう意味では業界としてだいぶ健全になったようにも思える。

2022-05-19

TypeScript

TypeScriptって静的型付け言語やってるとなんてことはないのばっかりだけど

動的型付けばっかやってた人には馴染みがなさすぎるのでは?

 

JavaScriptモダンフレームワークTypescript

学習ってかなりキツそう。特に初心者からロードマップイメージできない。

 

Javaメインの開発やってた人より。

2022-05-18

anond:20220518140216

おっちゃんが思うに、最後まで残るのはPHPだけど、

近いうちにウェブPythonでと考えるのが主流になりそうな気がしてる。

そうなるときは、当然、ララベル級のPythonフレームワーク誕生するんだろうけど、

Pyramidや、TurboGearsがその候補になるかと言われると微妙だぁなと思う。

2022-05-14

anond:20220514110458

ハードが十分に強くなったか

処理性能より開発しやすさを重視した言語フレームワークを出すのがトレンドになってるだけでしょ

2022-05-12

一番酷いのはMicrosoftフレームワークだけどな

WPF以降まともに使えるレベルに到達したものが一切ない

バージョン1.0という名の機能不十分なアルファ版を出して「こんなもん使えるかバーカ」って反応されて、投資価値がないと判断して次の製品を作り始めるから

おかしいだろそれよぉ!?

2022-05-06

RDBMSに拘る理由ってさ

ただこれらのDB現在広く普及しているRailsやLaravelやSpringなどのWebフレームワークSQL互換DBとの連携を基盤にしているので、それらから見たら非主流なWebフレームワークを使うことになる。

それこそ古臭いフレームワークを何時までも使ってるからだよね

15年前とか笑ってる場合か?

最初Railsリリースされて何年目だと思ってんだよ

17年目だよ17年目

いい加減に技術アップデートしろ

Rails使ってる身分で15年前の技術(笑)とか調子こいてんじゃねえぞハナクソ

2022-05-04

anond:20220504032546

普通フレームワークが不動になるのでは…

規約を重視すれば設計はぶれないはず…

最初は綺麗に作ろうとしてるんだけど、どんどん欲張り全部盛りみたいになってくシステム

フレームワーク入れてみてやっぱいらん

新しいテーブル作ってやっぱいらん

簡潔さとは程遠い。ぐちゃぐちゃになっていく〜ああ〜。

英語文法勉強してるんだけど

何かプログラミング勉強してるみたいな躓き方してる。

Html,css,javascript,phpみたいに勉強したら

次はDBが出てきたり、シェルスクリプトが出てきたり、

フレームワークが出てきたり、またDBで今度はストアドプロシージャだったりインデックスだったり

次々に知らない言葉が出てくるこの感じ。

高校生とかはこれらをどうマスターして、大学進学したり、大学進学後、英語論文とか書いてるの?

2022-05-02

anond:20220502093008

WEBスマホも移り変わりが激しくて参考書なんかすぐに使いもんにならなくなるやで

APIライブラリフレームワークメジャーな奴でネット上に仕様サンプルとか蜜からないのなんかないし参考書買うのは金ドブやで

anond:20220502093008

APIOSシステムコール、WebAPI、不変なもの

ライブラリ:何かの問題解決に特化してる、動画エンコードデコードとか

フレームワーク:数行でアプリ全体ができてしまいような雛形がある、ライブラリをチョイスして統合してある

呼び出し順として

フレームワーク

ライブラリ

API(WebAPIでも同じ)

みたいなイメージがある

APIライブラリフレームワークって全部関数だろ、無駄な言い換えで参考書売る商売やめろ

IT業界無駄言葉を作って新しい発明をしたように見せかける

お前らってそういうところあるよな

2022-04-29

anond:20220429222211

あーなるほどフレームワークか、そんなん無かったもんな

何ならフレームワークどころかライブラリすら無いとかザラだった

そのうち秘伝のタレみたいなライブラリができあがり、ひょんな事から「あ〜じゃあオープンプロジェクト提供しましょうか?」ってなる

anond:20220429221812

フレームワークが充実してて組み合わせて構築することがほとんどだから

自分でイチから実装する場合と違って設計フレームワーク流儀に合わせる必要があるのよ

anond:20220429185955

フロント周りのフレームワークは数年毎に新しいやつが出て知識レベルがある程度巻き戻るので

やる気さえあれば余裕で間に合う

2022-04-27

anond:20220427160318

いや、既に書いたとおり「サービスひとつ作ってみる」というのは「試合をやってみる」と対応する。

「壁に向かって球蹴ってみる」「リフティングしてみる」は「hello worldを出力してみる」「if文を使ってみる」と対応するか。

いわば「部分練習」と「通し練習」の違いだ。

サービスを作ってみよう」というのは、

プログラム仕様を知って、部分練習が出来たら、次は通し練習をしてみましょうね、

まだ分からないことも多いだろうけど実戦形式のほうが理解やすいですよ、ということにすぎない。

スポーツだって「口で説明するより実践してもらったほうが早い」ということはあるだろう。

その点ではコンセンサスを得られていると思う。

そしてプログラムというのは一人でも試行錯誤しながら「通し練習」できる性質がある。

ネットに転がってる見本をそのままコピペすれば動くし、

フレームワークなんかを使えばチュートリアルをこなすだけでそれなりのものが出来あがる。

そして間違っていたら「ここのバグのせいで動きません」と教えてくれたりもするのだ。

もちろんそれで誰に迷惑がかかるわけでもない。

しかスポーツ特にチームスポーツで同じように試行錯誤するのは難しい。

ルール戦術がわから試合に参加すると、試合の流れに取り残されてボールが回ってこない、

チームの足を引っ張って怒られる、わけもわからず反則をとられる、よくわからない理由で笑われる、

といったことが高い確率で起こりうる。

というわけでプログラムのほうが「とりあえず通し練習してみろ」が通用やす環境ではあると思う。

サッカーでも「いまからやるのは初心者ルールを教えるための試合です」と言ってちゃん知識のある人がフォローしながら練習試合をするならいいんじゃないかな。

2022-04-26

webデザインとそのフレームワーク流行ってマナー講師押し付け価値観みたいなもんだな

UXなんて二の次にして誰が言ったかで良し悪し決まってるよな

2022-04-12

anond:20220412040837

低いというか必要ないんだよなー

ウェブ界隈の意識高い系があーだこーだ言ってるのって本当に必要なの?って

セキュリティ系は公開するもの重要性高いものならある程度しっかりすべきだろうけど、それ以外のところって必要無いところのほうが多い

実際ガラケー時代文字リンク画像程度で十分だし、増田デザインでも十分

フレームワークがどーだこーだ言ってるようなムダな時間があればシステム一つ追加で作ったほうが稼げるだろうに

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