はてなキーワード: jqueryとは
jQueryだけど$('iframeのID名').contentDocument.locationで中身の要素にアクセスできなかったっけ
プログラミングってこれからの時代必要っぽいし、なんとなくイケてるスキルっぽい。
ゲームとかアプリとか作ってストアで公開とかしたら就職とか転職にめっちゃ有利じゃね?
俺はこういうのが出発点で良いと思う。
でもプログラミングを始めようとすると「何がやりたいの?」と聞かれてソッコー詰まる。
俺は「何をやればいいの?」って思って調べてるつもりなのに「何がやりたいの?」って突き放される。
ここで混乱して立ち止まってしまう。
でも一呼吸おいて、初心者とそれ以外の間に生じる認識の祖語について1つずつ解消しなければ先に進めない。
俺はプログラミングを覚えるということは、何でもできるようになることだと思っている。
でも先人たちはそのようなスキルをすぐに教えてくれない。それどころか「何をやりたいの?」と言って、他につぶしの利かない小さな範囲の知識を与えようとしているように見える。
「アプリ作りたい」と言えば、どんなアプリ?という問いが続くし、特定の具体的なアプリしか作れないような知識しかもらえないだろう。
どういうことか?
試しに「何でも作れるようになりたい」と言ってみると「じゃあC言語やろうぜ」とか言われる。
C?いまさらCで何作れるんだよ。AndoroidアプリはJavaじゃないの?C関係ないでしょ!?Cでスマホアプリもウェブサイトも作れないじゃん!何言ってんの!?
ち・が・う!何でも作れるようになりたいの!あんたみたいに!Visual Studioだろうとgccだろうと、cとかc++とかc#とかjavaとかpythonとかrubyとかphpとかテンサーフローとかhtmlとかjavascriptとかjqueryとかgoとか駆使してたくさんウェブサービスとかアプリとか作りまくってるあんたみたいに!
「じゃあ今挙げたやつ全部やれよ。ちなみに今の俺は10年以上プログラミング勉強してるから。10年後今の俺になったところで、俺はさらに10年積んでるからな。一生追い付かんな」
「じゃあ今、あるいはこれから使えるものを重点的にやっていくしかないな。で、何がやりたいの?」
何がやりたいのってどういうこと?むしろ何ができるの?
「アプリ作るとか」
「どんなアプリ作るの?」
…………どんなアプリ作れるの?
「ストアにあるようなやつ」
じゃあFGOみたいな……
「お前には無理だからw」
はぁっ!?ストアにあるようなやつって言ったじゃん!
そこでまた数回やりとりが発生して、プログラムを書くコストとかスキルの問題について再確認することとなり、
現実的に俺個人が支払えるコストの範囲で、何を作れるようなスキルを取捨選択するかという問題になり、
結局は教科書のサンプルをちまちま作っていくしかないのではないかというつまらない結論が脳裏に浮かぶし、
その道筋でさえ結局何年も積む必要があり、そのころには別の言語とか開発環境が主流になってるかも……
「そこだよそこ」
えっ?
「まずさ、日本語の教科書を読むには日本語が必要じゃん?それでも国語辞典とかwikipedia調べながら知らない単語や概念は別途補てんする必要がある」
う、うん。
「プログラミングの教科書とか風潮を読むにはプログラミングの基礎が必要。それに加えて、作りたいものに合わせて新規に開発環境なり言語なりを学習することになる。だから何でも作れるようになりたけりゃ、この世の全てを体得する必要があるけど無理だろそんなの」
え、えー
「でもいくつもの開発環境、言語を使って、ソフトウェアをいくつも実際に作ってると、基礎的な引き出しは大きくなるし、追加で新しい環境とかを学習する要領もつかめてくる。何年も積み重ねがあるとなおさらね。するとより少ない労力で新しい技術に追従できるし、新しい開発環境やアプリの分野でもサクサク作ってるように見える。それが、お前の言うところの『何でも作れる』ように見えるものの正体さ」
なんか夢から覚めた気分。
「FGOを作りたいなら、FGOをかみ砕いて、自分ならどういうアレンジでそれっぽいものを作れるか考えて、その過程で自分の能力とか限界を見極めていく必要がある。でもそれは結果論であって、最初は作りたいものをひたすら作ってみるしかない」
ふーん
「何度も聞くけど、何が作りたいの?FGOならFGOでいいよ。やってみろよ」
どうしよっかな……(頭を抱える)
ちなみに、jQueryが古くなって、新しく台頭してきたのが、Vanilla JSらしい。
俺も最近よく使ってる。
web系は一部に目立った高収入がいたのは認めるが、基本的には昔から高給のイメージはない。
「フルスタックエンジニアっていうインチキワードが横行」には完全同意。
一人でやらせるのは予算の都合ばかりじゃなく人によっては高品質・短納期となるから。
jQueryはもう古いと思われてるんだろうなというのはなんとなく分かる。
キーボード叩いてると突然ウっとなって涙がじわじわにじんでくる。きっかけはよくわからない。
涙がにじむとトイレにこもってできるだけ涙を排出し、自席に戻る。
涙が出るたび一々トイレに行かなければならないのが面倒くさい。
涙を出しきったつもりで自席に戻ってもしばらくは残尿みたいに止まらないのも面倒くさい。
そういうのが一々面倒くさいからそのまま涙流しながら仕事させてほしい。
なので泣きながら仕事してたら変に心配されてしまうと思うが、でももうデフォルトで涙がでてくるため
自分としてはなんかあくびとかくしゃみとか居眠りぐらいの位置づけであり、あまり気にしないでほしい。
居眠りしながら仕事してる人間もいてそれが黙認されてるくらいゆるい会社なので
泣くことも許してくれないかなあとおもう。
きっかけはエンジニアのおじさんに理系特有の早口でしゃべられた上長文赤字のメールを送りつけられたからだとおもう。違うかもしれない。
そういえば職場で始めて泣いたのはおじさんからバカでかいフォントの指摘メール送られてきたときだった。
なんでこんなにおじさんから圧かけられがちかというと、この分野の知識が本当に本当になく不勉強だからだ。
弊社はメガバンク系SIer会社なのだが、自分は最近までwebアプリの開発を担当していた。eclipseでjavaでjQueryでUNIXでshellだったのだ。
それが今のチームに異動となり、分野は一変、メインフレームでzOSでcobolでファンクションキーになったのだ。
最初はわからないことが多いけど弊社主力の分野なので頑張ろうと思った。社内研修かたっぱしからでてメインフレームで遊ぼうよんで
がんばってついてこうとした、でも座学だけでは知識は身につかなかった。
手を動かしたかったが、Sierとはコードは書かないし資源引き揚げもしないみたいだ。
そういうのは製造委託先のエンジニア達の仕事で、では我々は何をするかというと、エンジニアさんの作った内部設計書、
テストケース、成果物一覧、スクリーンショットを確認するのである。
でもそもそも何が確認観点で何がまちがってて何がどうなってれば正しいのかよくわからないのだ。
自分の会社の上司先輩に聞きたかったが、ある程度スキルをもった上司先輩は業務に忙殺されておりもはやふだんどこにいるかよくわからない。
というのも近年弊社では超大規模プロジェクトが発足しており、
ある程度スキルをもった人間はそちらに根こそぎもってかれてしまっている。
自分はメインは運用・保守・メンテナンスチームなので、そういう上司先輩とは関わりがない。
またこのプロジェクトでごっそり人がもってかれてるためメンテナンスチームの人間が少ない。なのでとにかく一人あたりの作業が膨大なのだ。
そして作業内容は前述のとおり。委託先のつくった成果物をチェックし、品質関連の定型的な資料をつくり、承認する。
なにをみたらよいかわからない成果物がどんどん送られてきてどんどんチェックしなければいけないのがつらい。
なにをしたらいいかわからないことをどんどんしなければならないのがつらい。
同じメンテナンス担当の先輩にきいてもよくわからないと返答がきたので
いまさらなにをそんなこと聞くんだみたいな雰囲気をにおわせながら
理系特有の早口でいまさらそんなこと確認しても意味ないですっていわれたからもうめんどうくさくなってしまった。
でもかつてはソースかいてテストして資源ひきあげする立場だった身をしては、ちゃんと確認したい気持ちがある。
でも同時に、とんちんかんな質問する担当者に対してエンジニアがイラっとする感覚も容易に想像つくので
もうなにもかもめんどうくさい。
明るくない分野の仕事をてさぐりでやらなければなければならないのがめんどうくさい。
チェックシートに日付をひたすら埋める仕事がつらい。※つじつまをあわせるために、全て同じ日付にしてはならない。
これらをやらなくてもどうせシステムはちゃんとうごくのがわかってるから尚つらい。
かつてソースかいてテストしてた時代は、ネットにあふれるイシキタカイキラキラサイシンギジュツブログと
自分が担当しているつまらなくぱっとしない時代遅れのwebアプリに不満を感じていた。
テストといってはひたすらスクリーンショットを延々と印刷する作業にいったいなんの意味があるのだろうと思っていた。
昨日Qiitaでメインフレーム関連の記事をあさっていたところ、zOSではteraTermによりUNIXライクな操作ができることを知った。
また、ftpが使えることも知った。ということはffftpが使えるかもしれない。希望の光に見える。うれしい。すごくうれしい。
USSが使いこなせればもうすこしこのメインフレームまわりに馴染みやすくなるかもしれない。
※補足
バックエンドのように地味で制限も多くいつまで経っても新しいものがあまり出てこない退屈なところとは違う
同じツールばかりで飽きることがない
案件で新しいのを使ってみて、次の案件のときにはもう次のツールが出てきているから使っていける
同じものばかり使って新しい体験がないまま同じようなことの繰り返しという退屈さがない
常に新しい体験ができる
JavaScript 自体がウェブだとこれ一択だったから、オブジェクト志向だったり関数型だったり比較的いろいろな使い方ができる
それぞれに合わせてライブラリがあるから好みの使い方をすればいい
型がほしいならtypescriptなどのaltjsもあって自分の好きなもので作れるわけだ
一部○○するならこれ、などと言い切ってる人がいるがそんなことはない
いいところもあれば悪いところもあるし、欠点があるからそれを補った別のツールが出てくるわけだ
ついていけないという人もいるが、新しいのが出続けるというのを理由に避ける必要はない
新しいのについていけない、めんどくさいという人は古いのを使い続ければいい
未だに jQuery やそれと同じくらいの時代からあるライブラリのみのサイトだって普通にある
それが悪いということもない
そういう選択もありだ
ウェブ系の仕事をしてるが気軽にIE対応とか言われることがあるが気軽に対応できるものではない
もう5年くらいは経つのだろうか
ChromeやFirefoxは1,2ヶ月程度に1回アップデートをしていて毎回様々な機能が追加されている
未だに昔ながらのjQueryのみという作りをしているのであれば大して気にすることではないがモダンブラウザをターゲットに最新機能をどんどん導入している場合はIE対応がかなり辛い
実際に倍くらいの時間がかかることもある
JavaScript コア部分であれば Babel で変換したりpolyfillである程度の対応はできるが DOM などブラウザ固有の WebAPI はそうではない
別途それぞれのpolyfillを集めて多少はどうにかできるものもあるがそれですら手間になる
またBabel等を通さなくてはいけなくなるだけでも十分に時間がかかる
frameworkやtypescript, flowなどを使っていて事前コンパイルが必要な構成であるならばさほど影響はないだろうが、モダンブラウザのみをターゲットにしてるならそういったツールなしでも十分に書ける
事前処理が必要になるだけで開発にかかる時間やめんどくささは大きく変わる
さらにはそういったツールのわかりづらいバグを踏んだり、ブラウザのdevtoolsでのできることが制限されたりもする
devtools といえばIEだとデバッグすら快適に行えない
IEでのみ発生する問題が起きると特定の難易度がChrome等の倍以上と言える
これだけの苦労がIEに対応させるだけで出てくるのにオマケで対応してという気軽さで頼んでくる人が多い
最初はIE11だけだったのにやっぱりユーザにいるから10と9もというケースもある
私はフリーではないから値段を好きには決められないが、決められるなら
IE9以上→x4
くらいは取りたい
IEを倍にすると高いと言われそうだが、モダンブラウザのみでいいなら昔ながらの作り方より何倍も簡単に作れるわけだから Chrome のみならの割引でもいい
HTML/CSSはリファレンスなしで書けるし、WAI-ARIAを用いたアクセシブルなコーディングもできる。
CSS設計を意識して保守性を大切にしたコードを書いているし、CSSアニメーションでインタラクションも操作できる。
SVGを一から書く方法やいくつものブレイクポイントを持ったページのコーディングスキルも身につけた。
Gitでバージョン管理をしたり、モジュールバンドラーやタスクランナーでscssのコンパイルやリントを通したりする能力も得た。
インプットが大好きで、毎日毎日様々なWebに関する知識を頭に詰め込んだ。
だけどJavaScriptは書けない。
JQueryをコピペして簡単なDOM操作を行うのが限界だった。
然しながら、昨今のフロントエンドエンジニアはJavaScriptが書けて当たり前だし、
各種JSフレームワークやWeb Assembly、Web Componentsを使いこなして開発している。
SSG, SSRが主流のこの時代、生のHTMLを書いているような人種は淘汰され、
バーティカルリズムや余白設計、配色理論を意識した整ったレイアウトをXDやIllustratorで作れるようになった。
でも「整った・整然としたレイアウト」は作れても、その先に進むことはできなかった。
だけど、藻掻き続けても道が拓けない。
もうこの先、どのように歩み進めればいいのかもわからない。
助けて欲しい。
何者にもなれない自分は嫌だ。
ドコとは言わないけど、増田の記事書くような感じの独自記法と一部HTMLが使えるところがある
そこにはプレビュー機能があって一文字打つごとに実際の表示が更新される
script タグも許可されているんだが、どうも内部では jQuery の html() メソッドにそのまま入れてるようで、プレビューが更新されるたびに script タグが実行される
先に script タグを書いていれば残りの本文を一文字打つごとに実行されるわけだ
script の内容によっては画面が崩れていくし、ヒドイにもほどがある
「script を最後に書く」+「今のURLがプレビューされるページだと実行しないような処理を最初に入れる」として対処できたが、これはもうバグといっていいんじゃないかと思う
普通に innerHTML にすれば script タグは実行されないようになっているのに なんでもかんでも jQuery なんて使うから・・・
使い方が悪いのが原因だが、jQuery の html() メソッド が script タグ実行させるなんて余計なおせっかい機能をなんで入れてるんだよ、とただでさえ嫌いな jQuery の嫌いさがさらに強くなった
副題:Androidで動くBASIC!でプログラミング教育を行うメリットとデメリット
01.はじめに
この文章は、Androidで動くBASIC!でプログラミング教育を行うメリットとデメリットに
02.BASICとは
BASICはプログラム初心者向け言語として1960年代に発表された古い言語です。
極めて簡単な文法とインタープリターによる即時実行や1970~80年代のパソコン
に無償で搭載されていたことから沢山の人に利用されていました。
しかし、簡単ゆえの機能の少なさと即時実行方式のための性能の低さやその後の
優れたプログラム言語発表によりBASICの利用は著しく低下しています。
03.BASIC!とは
BASIC!はアンドロイドのタブレットやスマートフォン上で動くアプリです。
Google playからインストール可能で無料で利用できます。
https://play.google.com/store/apps/details?id=com.rfo.basic&hl=ja
BASICの文法を踏襲していますが、Android向けに大幅に命令が拡張されており、
GPS等の各種センサーの情報取得やSQLiteのデータベース機能、WEBVIEWを利用
したHTML、CSS、JS表示・実行など約500程度の命令群で構成されています。
無料、広告なしのアプリをインストールするだけでこれらの機能が利用可能で
過去の栄光というかBASIC自体は広く利用された時期が過去に存在しパソコン
BASIC!は基本はBASICの拡張であり文法や変数の取り扱いにおおきな違いは
ありません。
その当時、少しであってもBASICを触った人は多いのでメンターとしての
BASIC!は手続き型と呼ばれる非オブジェクト指向の言語であり最新の言語
とは異なっています。
BASIC!のネイティブな命令群だけだと他の言語へのスムーズな移行は難しい
かもしれません。
しかし、BASIC!にはHTML5アプリのようにBASIC!自体のwebViewでHTML,JS,CSS
HTML,JS,CSSは現在Webの標準であり、進化を続けています。
特にjavascriptはオブジェクト指向の言語に進化し採用される領域もフロント
BASIC!自体のwebViewは他のAndroidアプリ同様、chromiumベースでAndroid
システムのWebviewの更新により常に最新化されています。
HTMLモードではjQuery,Angular,ReactなどのJSライブラリも利用できます。
最初はBASIC!ネイティブなプログラム→HTMLモードでJSを利用したプログラム
但しAndroid5.0あたりからAndroidシステムのWebviewが導入されているので
安いタブレットであれば1万円程度で新品が買えます。中古のスマホであれば
更に安価です。
またプログラムを作るのでキーボードもあった方がいいと思いますが
もちろんソフトウェアキーボード(フリック入力など)でもプログラムは
作れます。
パソコンよりもはるかに安価でプログラミング教育が実現可能です。
iPhoneの登場以来現在の子供たちはタッチパネルAndroidデバイスに
慣れています。
また教える大人側も日頃パソコンよりスマホを触る人は多いと思います。
f.可搬性が高い
ここで述べる可搬性とは別のデバイスで同じプログラムを動かす場合の
容易さの事です。
BASIC!はインタープリタなのでソースファイルのみを別のデバイスに
仮にHTMLモードの場合は併せてHTML,JS,CSSをコピーするだけです。
別のデバイスにはBASIC!さえインストールされていれば動きます。
BASIC!独自のプラグインや拡張モジュールなどは特にありません。
a.性能上の問題
BASIC!の実体はJavaで出来ています。すなわちJavaよりは性能は悪い
ことになります。
実際、大量の繰り返しや大量の文字列を扱うプログラムは性能が出ないので
Androidのスマホやタブレット自体もパソコンの演算能力には劣ります。
但し、プログラミング教育には大きな障害にならないと思います。
BASIC!はプログラムを作るアプリである以上当然文法エラーを実行時に
表示する仕組みになっています。
ただ一部エラーチェックが甘い部分もあり本来エラーとすべきところを
そのまま実行する場合もあり想定外の結果となる可能性もあります。
次にエディタは単なるテキストエディタと同等の機能しかなく最近の
エディタにあるようなシンタクスハイライトや入力補完といった機能は
ありません。
ただ比較的シンプルなプログラムを作る教育では大きな影響は無いと
考えています。
c.一部機能に制約がある
前述の通りHTMLモードではJSが動かせます。ただし制約があります。
非同期通信などを行おうする場合、JSが実行時エラーになる可能性が
あります。
またデータベース機能であるSQLiteへの操作についても文字型項目しか
利用できない制約があります。
JSがローカルモードのみなのは教育の事を考えると少し残念ですが
d.参考となる文献がほぼない
該当する書籍がないのが実情です。
■BASIC! ~ 分かりやすい教本で一から学べるコンピュータ言語 - Android★SQUARE
http://blog.livedoor.jp/an_square/archives/51887786.html
BASIC!の文法自体は極めて簡単なのでどうにかなると思います。
06.結論
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
ScalaとかKotlinとかいろいろ言ってる奴いるが10年後にはどうせJavaが勝ってる。
Javaはnull安全じゃない!とかほざく奴はもちろん@CheckForNullアノテーション使ってから言ってるよな…?
フレームワークは流行り廃りがあるから微妙だが、勉強するならSpringにしておけ。それだけでいい。
Webブラウザに標準搭載のJavaScriptが無くなることもまずありえない。
あとやるならjQueryね。AngularJSとかすぐ廃れるから。
学習コストが高いものって結局広まらないからさ…素直に現実を認めよう。
AnsibleやFabric使ってるやつがいるがどうせ10年後にはブームが去り技術的負債となっている。
シェルスクリプトで代用できるのだからシェルスクリプトでやっておけ。
これだけ広まったRDBが今後使われなくなることはまず考えられない。
なんか最近Webフロントエンド界隈でイキっている人良く見るけど、そもそもどのくらいの経験で語ってるんだろ。
感覚的には、10年前はすっごいしょぼいJavaScriptばっかだったし、それで要件を満たせてたと思うんだけど。
複雑な要件のときは、JavaAppletとか使ってたような。
ちょっと昔を振り返ってみると、
5年前はJSFがすっごいイケてるように思ってたな。今は完全に終わってるけどね。
10年前は、これからはprototype.js じゃなくてjQueryだ!と思ってた時代かな?
20年前は、JavaScriptは、ブラウザのステータスバーに文字を表示したり、マウスの動きに合わせて星をキラキラさせるのに使ってたかな。
WEB始まりすぎだし、アプリもゲームも始まりすぎなんですけどって話
WEBに関してはruby/railsとかは900万超えの求人出しても来てくれないくらいには好調です
HTML/CSS/JS/Railsができて仕事ないとか言ってる人いたら教えてほしいくらいだよ
俺の会社他にアプリ部門があるんだけどもっと人が足りないって愚痴ってるしこのままだと1000万行くかもしれない、うらやましいくらいの話だ
まぁ結局はてなも2chもそうなんだけど、ネットで愚痴ってるやつって仕事できない無能が8割か、転職怖い昇給交渉怖いって動こうとしないビビリのクズか
それか若者つぶそうとして楽しんでるやつか、なにかしらの病気なので相手にしないほうがいい
進化が早すぎてついていくのがつらいよーってやつの話にも聞かないほうがいい
追加された機能をゴリゴリ生かさなければいけないなんてシーン俺は知らない
まぁ大きく変わったのはFLASHが廃れて」、HTML5/JSで代替しなければいけなかったことくらいだけど
べつにそれに関しても大した話じゃない。ゆっくり以降していった話
フロントエンドはつらいなんて話をよくしてる連中いるけど、ただの馬鹿がファッションで乗って、つらさを自慢しあってるだけ
あいつらがやってることの9割は必要ないことで苦労してると思うわ
gulp/grantなんかのタスクランナーとかする必要ないのにして変化が激しいとか愚痴ってる意味の分からない
anguler/ract/vueあたりもな
SPAなんて特殊なものをこれから来る必須技術みたいにさわいで技術飛びついて変化が激しいって騒いでスターもらいたがってるだけ
結局ブログで承認欲求みたすための苦労自慢でリスカ女と変わらないので相手にする必要なし
railsは変化が速いのでは?なんて話も真に受けるな
たしかに3くらいまでは俺自身が慣れてなかったからつらかったといえばつらかったが、その程度の変化ほかの業界でもいくらでもある
なによりネットにドキュメントが大量にある、はっきり言ってほかの産業にくらべて勉強が楽なくらいだ(ググるときに注意が必要だけど、情報の鮮度とか正確性とか)
railsはフレームワークが1強なので迷わなくていいし仲間も多いから、かりに変化がおこっても、頭のいい人がドキュメント残してくれるし、勉強で困ったことなんかほぼない
5.1でjquery依存をなくすとか、CoffeeScript廃止とか、yarn採用も困らなかった
もう一度言う
プログラマーになりたいと思ってる君、情報工学部(コンピューターサイエンスやる学部ね)行こうね、私は大学で電気科に言ったんだけどいまだに後悔してる
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年に追いつけよ。