  |
はてなキーワード: フロントエンドとは
わからん、フロントエンドエンジニアとかの下りは特にわからん、アンタが妙なコンプレックス持ってるだけだと思う。単純に自分の役割をきちんと示してるだけだと思う。
インフラエンジニアに対する理解力の低さから、まぁ、IT全般に弱いんだろうな、頭弱いんだろうなというのは判った。ネットワーク設計とかルータの設定が「サーバ屋」に含まれてると思っている、と言い切るなら、まぁキチガイの一種か、本当に頭弱くて理解力が低いだけだろうな。
サーバだけ出来ればインフラエンジニア出来ると思ったら大間違いなんだよ。だからサーバ屋じゃなくインフラエンジニアなんだよ。ネットワーク設計だって技術力が必要な立派な仕事だよ。ルータだけで数千台あるようなネットワークを構築するのは誰か、インフラエンジニアだよ。それが技術じゃない、サーバの技術のおまけっていうなら、あんたがIT業界去った方が業界のためになるっていう理屈、判るだろう。
職種をキラキラさせすぎた結果、勘違いが生まれ、キャリアパスアピール、虚飾、承認欲求がひどくなった
WEB始まりすぎだし、アプリもゲームも始まりすぎなんですけどって話
WEBに関してはruby/railsとかは900万超えの求人出しても来てくれないくらいには好調です
HTML/CSS/JS/Railsができて仕事ないとか言ってる人いたら教えてほしいくらいだよ
俺の会社他にアプリ部門があるんだけどもっと人が足りないって愚痴ってるしこのままだと1000万行くかもしれない、うらやましいくらいの話だ
まぁ結局はてなも２ｃｈもそうなんだけど、ネットで愚痴ってるやつって仕事できない無能が８割か、転職怖い昇給交渉怖いって動こうとしないビビリのクズか
それか若者つぶそうとして楽しんでるやつか、なにかしらの病気なので相手にしないほうがいい
進化が早すぎてついていくのがつらいよーってやつの話にも聞かないほうがいい
追加された機能をゴリゴリ生かさなければいけないなんてシーン俺は知らない
まぁ大きく変わったのはFLASHが廃れて」、HTML5/JSで代替しなければいけなかったことくらいだけど
べつにそれに関しても大した話じゃない。ゆっくり以降していった話
フロントエンドはつらいなんて話をよくしてる連中いるけど、ただの馬鹿がファッションで乗って、つらさを自慢しあってるだけ
あいつらがやってることの9割は必要ないことで苦労してると思うわ
gulp/grantなんかのタスクランナーとかする必要ないのにして変化が激しいとか愚痴ってる意味の分からない
anguler/ract/vueあたりもな
SPAなんて特殊なものをこれから来る必須技術みたいにさわいで技術飛びついて変化が激しいって騒いでスターもらいたがってるだけ
結局ブログで承認欲求みたすための苦労自慢でリスカ女と変わらないので相手にする必要なし
railsは変化が速いのでは？なんて話も真に受けるな
たしかに3くらいまでは俺自身が慣れてなかったからつらかったといえばつらかったが、その程度の変化ほかの業界でもいくらでもある
なによりネットにドキュメントが大量にある、はっきり言ってほかの産業にくらべて勉強が楽なくらいだ（ググるときに注意が必要だけど、情報の鮮度とか正確性とか）
railsはフレームワークが1強なので迷わなくていいし仲間も多いから、かりに変化がおこっても、頭のいい人がドキュメント残してくれるし、勉強で困ったことなんかほぼない
5.1でjquery依存をなくすとか、CoffeeScript廃止とか、yarn採用も困らなかった
もう一度言う
プログラマーになりたいと思ってる君、情報工学部（コンピューターサイエンスやる学部ね）行こうね、私は大学で電気科に言ったんだけどいまだに後悔してる
プログラマーなんかIT土方だしとか言われてて電気か機械のほうがいいといわれて私は電気を選んだんだよ
wordpress最盛期。あの案件もこの案件もWordPressを使って、プラグインましましjqueryましまし脂マシマシな納品が星の数ほど生まれていく。「プラグインが最新バージョンに対応しないので、本体のバージョンアップができません」といってセキュリティホールだらけのwordpressが放置される。アホかと、バカかと。
フロントエンドはhtml,css,javascriptでつくるものだよ。expressをみて「javascriptでバックエンド書くの？気持ち悪い」っていってただろ。それと同じだ。いつまでphpでフロントエンド書くつもりだよ。phpで動的生成し続けるから、いつまでもwp headでwordpressのサイトってバレてアタック受けるんだよ。とりあえずurlの末尾にwp-adminってつけて確認されるんだよ。
分離しろ、分離。wordpressの管理画面が悪いとはいわない。あいつはいいやつだ。けど、wordpressでフロント書く必要はない。wordpressもrest apiだしただろ。更新はwordpressでやって、その情報をapiで取得してきたらいいんだ、それでいい。
wordpressでテーマをつくるのがキャッチだった頃からもう6年はたった。6年前といえば、Windows 7使ってた頃だよ。ヒカリエまだできてない。そんな頃のやり方つかって「これがスタンダードです」とかいってクライアントをだまくらかして楽しいか。さっさと2017年に追いつけよ。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
Reactクソって言い続けて来たけど、新規顧客からReactじゃないとやらんとか言われて失注したので今更ながらやってみた。
1週間使ったけど、良いねこれ。VueJSでReactiveなフロントエンド開発はやったので意外とすんなり理解できた。
これを機に自分のFrontendのスキルセットを、ES6、Webpack、Flux、React-Route、Reactに刷新した。
今までは、Gulp、VueJS、Browserify、BackboneJS、jQuery。。2014年位のスタンダードだよなぁ。
まさか『登録が完了しました』からの『誤動作によるご登録につきましては、メール・電話にてご連絡の上退会申請、キャンセルを行ってください。』
なんて古典的なページを、21世紀にもなってお目にかかるとは思わなかった。
ページをスクロールしていくと『ご利用料金』があり、税別で数十万の値が記載されている。
『お客様ID』『ご登録完了日時』はページをリロードしてもcookieを削除してもそのままであった。
Torブラウザー経由でアクセスすると『お客様ID』『ご登録完了日時』が変化したため、
おそらくアクセスIPに紐づけて日時等を保持しているのではないかと予想する。
『お支払期限』は三日後に設定されていた。
その下には『利用規約』『注意事項』が並ぶ。『有料サービスにつき必読』ともある。やさしい。
流し読みしてみると、『再生ボタンを利用規約認証としその先に進みますと当該内容の確認及び承諾をしたものとみなされます。』という。
『本サービスはアダルトに類される画像、映像の表示、配信を行っているため、勤務先や第三者の所有しているパソコンからの利用を禁止する。』ともある。
『会員の都合による一方的なキャンセルは受けられないものとする。本サービスはクーリングオフの適応対象外である。』という。
そのように言えばそうなるのだとは存じ上げなかった。
ここまで鼻で笑っているユーザーを想定してか、『悪質ユーザーへの対処の流れ』という記載がある。
『[1.書類送付]（滞納1日目）』『[2.回収代行業者へ委託]（滞納3日目）』『[3.少額訴訟（全額請求）]』というように、法的な手段も辞さない構えをアピールしてくる。
但し書きの書式が3つめだけ異なるのが気になるが、些細な問題であろう。
『しかし、このような対処方法はお客様の社会的地位や社会的信用を傷つけてしまいますので、理由の如何によっては滞納料金の免除等できる限りのご対応はさせて頂きたいと思っております。』
動画視聴サイトの会員登録という体のサイトで違法ダウンロードによる著作権侵害の話を持ち出すのはよくわからないが、
要するにタダで見るのではなく金を払えということを言いたいのだろう。
『【そんなつもりはなかった】【何も知らなかった】【みんなやっているはず】そういう言葉は法律では一切通用致しません。』と記し、
両手に手錠をつけた画像を大きく貼り付けて文章の締めとしている。
私も三日後にはこうなってしまうのだろうか。
HTMLのソースを眺める。『<!-- sample -->』『<style>』『<span style=』など、手作り感のある牧歌的なコードであった。
多数のコードがコメントアウトされている箇所があり、おそらく画面遷移によるページの差分をコピペで使いまわして修正しているのではないかと予想する。
読み込んでいるjQueryのバージョンは1.9.0であった。なお、現時点におけるjQueryの最新バージョンは3.2.1である。
URLの拡張子をそのまま信じるのであれば、使用言語はPHP。
404ページ出力をそのまま信じるのであれば、使用WebサーバーはApache。
極めてオーソドックスな構成であり、技術の習熟や人員の招集において比較的苦労せずに済みそうである。
この架空請求サイトのドメインは 2017-05-11T07:24:01Z に登録されたらしい。わりと最近の話である。
申請者の情報は 『Privacy Protection Service INC』 なる企業のものになっていた。
privacyprotect.org は whois 情報の代行を担うサービスらしい。勉強になった。
ドメインレジストラは publicdomainregistry.com で、 Abuse Reports よりフィッシングサイト等を通報できる体制になってる模様。
しかし、入力フォームに自身の名前やメールアドレスを入れる必要があるので面倒臭そうではある。
やはり、こういう架空請求サイトは国外を拠点にして取り組むらしい。
こんなものであっても、サーバーやフロントエンドの知識をそれなりに勉強した人間が関わっているはずで、彼/彼女の人生はそれでよかったのだろうかと思いを馳せずにはいられない。
ちなみにサービス名でググると悪質業者や架空請求について注意を呼び掛けるサイトがいろいろ出てくる。
自分はいま一般的にこう呼ばれる仕事をしてるが、正直他のエンジニアより明らかにレベルが低いと思う。
他の職種もやってきたので、如何にフロントエンドエンジニアたちがそうじゃないと言おうが、そうだと断言できる。
当人たちも薄々勘付いてると思うのだけど何故か認めようとしない。
どう考えても、html/css/jsなんて他の言語より簡単だろ
最近はreactとかangularとかあるし、es6だの、webpackだの、色々あるから難しいんだ、って意見がありそうだけど、いやそんなもん他の言語でもフレームワークやビルドツールやまほどあるだろ
ここ半年ぐらいずっとwebデザイナーになりたいと思って就活してるが、貯金とかもやばくなってきたので他の人に相談したいと思ってこの日記を書く事にした。
昨年の11月くらいに無職になってそこから1月から職業訓練行って3月末で終了して、そこから就活してるが、なかなか決まらん。
デザインとかはあまり得意ではないのでどちらかとエンジニアになりたいけどいきなりエンジニアとか無理だろうなと思って、デザイナー狙いながらやってる。
アルバイトとかにも募集してるんだけど作品見てもらってアウトー！！みたいな感じ。
その間にもプログラムの勉強とかしながらやってるけど決まる気配もない。
「保育園落ちた日本死ね！！」とは言わないが同じぐらいの気持ちである。
現職でそういった職業についている人はどうやって業界に入ったのだろう？
教えてください。
ふと思い立ったので書いてみる。二年前、新卒として某企業の技術研修を受けた。Javaを用いて、自分たちで一つのプロダクトを作るという研修である。技術を推している会社なので研修内容にはかなり期待していた。Spring等のフレームワークの話、JavaとフロントエンドのAngularやReactをどう連携させるか、もしかして自作のフレームワークを作る研修も受けられるかも、などなどの話を入社前にはしていた。実際そうではなかったわけだが。
詳らかに書くことは出来ないが、当時最も憤ったのは研修の成績をどうやって決めるかに関する講師の考え方。中間発表で企画発表を行い、最終発表でプロダクトとしてのレビューを受けて、プレゼン大会を行って成績が決まった。自分はどちらも中くらいの成績だったらしい。
ここで驚いたのが、コード量が成績評価に結び付くということだ。コード量の最適化という意味ではない。フレームワークなどを使ってコード量を減らしてはいけない、フルスクラッチでプロダクトを作れということだった。意味が分からなかった。
評価するためには十分量のコードが必要ということは理解していた。過去の研修で何人かがフレームワークを用いて適当に作ったプロダクトで済ませようとしたエピソードなどを聞かされた。それはわかる。わかるが、そうした怠慢に基づくモチベーションではなくよりよいプロダクトを作るために先人の肩に乗るのは許されるべきではないのか？
Javaによるプロダクトを理解するため、フレームワークを使うとフレームワークが廃れたときに何にもできなくなる、という言葉を何度も聞かされたが、Javaのプロダクトを理解するのならそれこそフルスクラッチを要求するのではなく歴史があるSpringで十分だし、フレームワークを使ったからといって魔法のように自分の望むプロダクトが出来上がるわけもなく、自分で考える部分が大部分を占めることは自明ではないか。むしろ、その考える時間という本質的な部分を確保するためにフレームワークなどの技術を用いるべきではないのか。
Reactを学びたいモチベーションがあり、Java側でなければ、というかReactはフレームワークじゃないし大丈夫だろうと思って実装を進めていた時に講師の方から「フレームワークは認められない」と言われ、食い下がったもののまるで話が通じなかった。結局自分はそこから大きく計画を修正し、適当なプロダクトを作った。モチベーションは地の底に落ちた。そもそもプログラム研修なのに渡されたPCがWindowsで、エクセル地獄だった時点でモチベーションはまるで高くなかったがReactをやるというのがモチベーションになっていた。それも無駄だった。
今年の新人も同様のカリキュラムだという。しかもまだWindows。フレームワークは一切使えない。エクセルでワイヤーフレームを書けという。SIじゃないから大丈夫だろうと思っていたのに、という新人はたくさんいるだろう。配属後もコードを書く時間はどんどん減っていく。自分自身で勉強し、論文や技術書を読み、週末に自分でプロダクトを作る習慣をつけておかないといけない。自衛しないといけない。
そんな不幸な人たちがいればいいのにと思った。
勉強が不得意な職業プログラマですが、WindowsアプリをSPAに作り替えることになりそう。
プロジェクトメンバーに積極的に技術を習得するような人はいないので、簡単なフレームワークを探しています。
↑に近いようなフレームワークありませんか？
増田の用途だとAccess使っても結局フロントエンドでExcel使わんといかんような気がするので、おすすめしない。
ソートに関してはマクロとかで改良できると思うが、重くなる問題はどうしようもなかろう。
ハードウェアのアップグレードで対応するという姑息な手段もあるが、Excelファイルは肥大化していくだろうから、問題を先送りにするだけという気もする。
きちんとしたデータベース（SQL）の知識があれば解決できるのだと思うが、かなり敷居が高い。
似たようなことでずい分昔に悩んだことがあるので、思ったことだけ書いた。参考にはならんな。
