  |
はてなキーワード: HTTPとは
| 商品名 | 値段 | 強度 | 紫外線UVカット(室内の色あせ・ 変色を防止する) | 貼り付けタイプ | 特徴 | 柄 | アドレス |
|---|---|---|---|---|---|---|---|
| ＵＶカット2倍強い明るい障子紙 (幅25cm×長さ22.5m) | 1001 | 約2倍 | 約95％カット | のり | 室内が明るく感じられる。（※1） | 無地、雲竜、笹竹、桜 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001889&search=%BE%E3%BB%D2%BB%E6&sort= |
| ＵＶカット2倍強い明るい障子紙 (幅28cm×長さ18.8m) | 1001 | 約2倍 | 約95％カット | のり | 室内が明るく感じられる。（※1） | 無地、雲竜、笹竹、桜 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001888&search=%BE%E3%BB%D2%BB%E6&sort= |
| ＵＶカット2倍強い明るい障子紙 (幅69cm×長さ7.2m) | 1078 | 約2倍 | 約95％カット | のり | 室内が明るく感じられる。（※1） | 無地、雲竜、笹竹、桜 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001887&search=%BE%E3%BB%D2%BB%E6&sort= |
| ＵＶカット2倍強い明るい障子紙 (幅94cm×長さ15m)ＵＶカット2倍強い明るい障子紙 (幅94cm×長さ15m) | 2123 | 約2倍 | 約95％カット | のり | 室内が明るく感じられる。（※1） | 無地、雲竜、笹竹、桜 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001886&search=%A3%D5%A3%D6%A5%AB%A5%C3%A5%C82%C7%DC%B6%AF%A4%A4%CC%C0%A4%EB%A4%A4%BE%E3%BB%D2%BB%E6+%28%C9%FD94cm%A1%DF%C4%B9%A4%B515m%29&sort= |
| ＵＶカット2倍強い明るい障子紙 (幅94cm×長さ7.2m) | 1166 | 約2倍 | 約95％カット | のり | 室内が明るく感じられる。（※1） | 無地、雲竜、笹竹、桜 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001874&search=%BE%E3%BB%D2%BB%E6&sort= |
| 浮世絵障子紙 | 3850 | 約４倍 | 北斎の名画。納期が多少かかる場合があり。 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001935&search=%BE%E3%BB%D2%BB%E6&sort= | |||
| ディズニープリンセス障子紙 | 3850 | 約４倍 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001931&search=%BE%E3%BB%D2%BB%E6&sort= | ||||
| ピクサー障子紙 | 3850 | 約４倍 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001929&search=%BE%E3%BB%D2%BB%E6&sort= | ||||
| くまのプーさん障子紙 | 3850 | 約４倍 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001927&search=%BE%E3%BB%D2%BB%E6&sort= | ||||
| ワークソン ピーナッツ（スヌーピー）障子紙 | 3850 | 約４倍 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001925&search=%BE%E3%BB%D2%BB%E6&sort= | ||||
| エヴァンゲリオン 障子紙 | 5500 | 約４倍 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001923&search=%BE%E3%BB%D2%BB%E6&sort= | ||||
| 北斗の拳 世紀末和室伝説 障子の章北斗の拳 世紀末和室伝説 障子の章 | 5500 | 約４倍 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001920&search=%CB%CC%C5%CD%A4%CE%B7%FD+%C0%A4%B5%AA%CB%F6%CF%C2%BC%BC%C5%C1%C0%E2+%BE%E3%BB%D2%A4%CE%BE%CF&sort= | ||||
| アイロン貼り超強プラスチック障子紙 | 1573 | 超強(※2) | 約95％カット | アイロン | 無地、雲竜、桜宴、市松、優花 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=005001000056&search=%BE%E3%BB%D2%BB%E6&sort= | |
| 夏涼しく冬暖かい障子紙 | 1414 | 約95％カット | のり | 無地、桜、雲竜、 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001558&search=%BE%E3%BB%D2%BB%E6&sort= | ||
| のり貼り超強プラスチック障子紙 | 1210 | のり | 無地、雲竜、桜、 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001777&search=%BE%E3%BB%D2%BB%E6&sort= | |||
| 4倍強いアイロン貼り破れにくい障子紙 | 1128 | 約４倍 | 約90％カット | アイロン | 無地、雲竜、笹竹、桜 | ttps://e-shop.asahipen.jp/shop/shopdetail.html?brandcode=000000001794&search=%BE%E3%BB%D2%BB%E6&sort= |
※１「室内が明るく感じられる」…アサヒペン社の説明の通りではこのようになっています。ただし恐らくですがプラスチック障子であれば全ての製品がこの特徴を持つのではないでしょうか？
※２「超強」…破裂強度が測定できない物。これはプラスチックシートを使用している為。
ウクライナ住民からパンと紅茶…涙を流すロシア兵士（中央日報日本語版） - Yahoo!ニュース
なんで寒い屋外で右手にパンを左手にコップを持たせて立ち食いさせてんねん。
家屋が無いとしても映像を見る限り乗用車はたくさんあるから、せめて車内で座らせて食わせろよ。
この時点ですでに演出過剰で嘘くさいのに、さらに隣の人がスマホ画面を見せてテレビ会話をさせるとか、短い映像の中に情報を詰め込もうと必死すぎやろ。
私には軍人もしくは反戦運動家が作り上げた三文芝居レベルのプロパガンダにしか見えないのだが、様々なブログでは真実であることを前提にお涙頂戴文章や反戦・反露主張を垂れ流してやがる。
ウクライナ侵攻に関してフェイク動画がネット上に蔓延しており、ネットメディアはフェイクニュースに注意するよう呼びかけしているけれども、脊髄反射で感動コメントを垂れ流している人には届いていないようだな。
もしも、この動画がフェイクだと明らかになったら、感動コメントを垂れ流していた奴は「俺はおかしいと思っていた」などと反省もせずに手のひら返しをするんだろうな。
https://news.ycombinator.com/item?id=29918052
https://bugzilla.mozilla.org/show_bug.cgi?id=1749908
about:config で network.http.http3.enabled を検索し値を false にする
不思議なのは、ycで報告されたのが96がリリースされて十数時間経過した39分前で
追記:
CloudflareでJST 17時に行われたデフォルト設定の変更が原因でFirefoxに以前から存在したHTTP3のバグが誘発されたらしい
なので、それまでは動いていたそうな
その辺の指摘が正しいのではないかと思うんだけど
そもそもはJavaで分散オブジェクト指向が流行したのが問題の歴史的な発端だと思ってる
つまり、RMI（いわゆるRPC）とかCORBA（それは紛れもなくヤツさではないです）とかHORB（産総研だっけ？）とか、
ネットワーク透過だのRPCのスケルトンだの、そういう話が発端な気がする
つまり、インターネット上ではマシンは当然ネットワークで繋がってはいるけど、
マシンAのJavaのプロセスがマシンB上のJavaのクラスを読み込んで実行できたり、
マシンBに肩代わりさせても、それを意識しないように書けると便利だよね、
という話であって、
ぶっちゃけ、今になっても、
世の中的に、今はJavaよりイケてると思われてる言語にも、この手のネットワーク透過にする機能とか、
よー知らんけど、クラウドコンピューティング（）だなんだの機能としてあっても不思議ではない気がする
昔で言うなら、ソニーのTelescriptとかよー知らんけど、
ネットワーク上の複数のマシンを渡り歩くプロセスというかプログラムみたいなのが実現できるのって、
今になって考えてみると脆弱性の温床でしかない気がするし、理解はできる
理解はできるが、じゃあ、まったくメリットがないのかというとそうでもなくて、
しかし、Javaのかつての流行が放置されたままになってるとか、そういう問題はあるわけで、
その辺がセブン＆アイだったかの、Struts2のOGNLインジェクションもそんな感じで、
ぶっちゃけ、マシンAからHTTPでマシンBのJavaクラスとか実行できたら便利だよね、みたいな話で、
マシンAとマシンBが外のネットワークと敷居があるという前提があるから問題がないのであって、
CGIでもよくあったけど、サーバー側の任意のコマンドを実行できるというのは、
サーバーの状態を監視するとかには便利だけど、当たり前だけど危険だよね、という話であって
眠くてまとまらない…
おやすみ…
あ、言い忘れるところだった
知らんけど
昨日見つけたいくつかのGitHubのリポジトリを面白く眺めてる
20代のフランス人だったり、40代のブラジル人だったり、色々である
ブラジル人は体力有り余ってるのか、
絵だとやりにくいなぁ、と思ったりする
みんなでブクブク浸かって楽しむみたいな世界は、
で、思ったのは、やはりプログラミングというのは、
過去のゲームがルールの発明だったこととかは古臭いものとなり、
コードも言葉と同じように無償で自然と発するものに近づいていく
ここで思うのは、スティーブ・ジョブズがこの世界をIBMの、
いわゆる、ソフトはハードのおまけ、の世界に戻したことであり、
ビル・ゲイツだったか、ソフトウェアは無償化していくという予言は当たっていたのだろう
それをマネタイズするには、ApacheでWebサービスを立ち上げるみたいな、
いわゆるGNUライセンスであれ、運用やサポートではお金が取れるが、
Node.jsを開発したら、開発者は当たり前だが一番Node.jsに精通しているわけで、
企業を顧客にNode.jsのサポートを有償ですることでマネタイズできる
ソフトウェアは無償化し、コードは会話のように無償で、ライブなものになり、
あー、そういう世相を予測して、
先に牛耳っておこうという点でMicrosoftによるGitHub買収は正しかったのである
ソフトウェアがなんでも無償に向かうのはMSとしても良くは思えない動きだったはずだが、
今はまったく反対方向にMSは向かっており、収益の基盤をAzureなどに移している
今すぐはありえないが、WindowsというOSも意味はなくなっていく
これはAppleやGoogleのような企業でも同じ考えのように思う
もちろん、そのレベルでのシェア争いや小競り合いが今すぐ消えてなくなるわけではないが、
長い目で見ればいつかはそうなっていくことは容易に予想できるわけで、
つまり、ソフトウェア産業というか、近年のバズワードでもあるテック産業というのは、
人生だって、みんな崖に向かって歩いたり、走ったりしてるだけである
その崖がどれだけ近いか遠いかとか、どれぐらいのスピードで崖に向かってるかとか、
それだけの違いであって、誰もがいつかは崖に到達して落ちる、つまり死ぬのである
しかし、そこには一発逆転や一人勝ちするチャンスも乏しくなり、
そういった金を求めるギラギラしたアブラギッシュは寧ろ嫌悪される存在となり、
しかし、そうやってった末に待っているのはコモディティ化であり、
ただの暇つぶしにさえなっていく
今は楽しい
でも、その楽しさの果てに死が待っている
Non-Fungible Token、日本語だと非代替性トークン。
紙幣・硬貨・暗号通貨のような「価値自体がその物体を表している」ものが代替性。例えば私が持つ1万円札とあなたが持つ1万円札は同じ価値のものとして交換可能。
そうでないものは全部非代替となる。非代替性を持つトークンなので非代替性トークン。
それは結局契約次第。例えばNFTはコンサートチケットのようなものに対しても適用できるが、これは別に会場の席を所有する契約ではないだろう。
同様に、NFTアートに関しても、「改変はOK/NG」「SNSアイコンに使うのはOK/NG」「商用利用はOK/NG」みたいな話をそれぞれで行うことはできるだろう。
その内容をNFTに埋め込んでしまえば後から契約内容を勝手に変更されることもなくなる。
（そういう運用をあまり聞いた事がないので、みんな適当にやっているのかもしれない）
この指摘は半分正しいが、半分間違っている。
正確には、NFT自体はそこに責任を持つようには設計されていない。また、リンク先が変わってしまうかもしれない問題は、NFTの問題ではなく現在の中央集権インターネットの問題である。
実際に現在の中央集権インターネットでは、電子書籍プラットフォームが倒産したときに「購入したリンク先の電子書籍が読めなくなる」、geocitiesがサービスを終了すると「リンク先が全て404になる」、という問題が発生している。
これを避けるために、NFTアートに利用するリンクには、HTTPに代わってIPFSという技術を用いるのが一般的である。
HTTPはロケーション指向などと呼ばれ、現実世界の住所に近い。当然その住所で火事が発生したり、泥棒が入って内容物が奪われたりしたら、中身のデータは失われてしまう。インターネット世界に戻すと、データを保管しているサーバが爆発すると、二度とそのデータを入手することはできない。また、データがすり替えられる可能性もある。
IPFSはコンテンツ指向などと呼ばれ、現実世界のISBNコードに近い。ISBNコードさえ知っていれば、どこで入手したものであっても自分が読みたい本と同じ中身のものを読むことができる。そして、IPFSではデータは分散して保管される。1つのサーバが爆発しても、必ず他のサーバから取得することができる設計となっている。データを分散させることによって、データの改竄にも堅牢となる。
ブロックチェーンを利用することで、悪意を持った何者かによってデータの改竄がなされない（正確には、相当なされにくい）ことを保証できる。例えば、「ザッカーバーグがFacebookの投稿を改変したが、Facebookがそれを認めないし、他の人は証拠を出すことも難しい」みたいな状況がそもそも発生し得ない。
暗号通貨であぶく銭を手に入れた連中が買っているから。適当に買い漁ってる人もいるだろうけど、資産の分散が狙いなのではないかと思っている。
今の為替で「1000万円相当の暗号通貨で買ったNFT」は、将来的に暗号通貨の価値が下がったとしても「その時点において1000万円相当の暗号通貨」で取引できる可能性がある。逆に暗号通貨の価値が上がったとしても、「買った時点と同じ量の暗号通貨」で取引できる可能性もある。
わからない。ただSkebは明らかに中央集権的サービスではあるので、非中央集権インターネットが流行ると困るのかもしれない。
あたなは何か勘違いしているナリ
HTTPプロキシは基本的に CONNECT メソッドを通じて通信するナリ
それ以外の場合は socks プロトコルで通信するナリ（なので基本的に Proxy を通すとは HTTPプロキシを通すということで、その場合 CONNECT メソッドが必ず必要）
CONNECT は基本的にHTTPメソッドを経由して通信するが socks は HTTP とは全く異なるプロトコルなり
（プロトコルというより通信のレイヤーが異なる。socksはISO参照のセッション層だがHTTPはアプリケーション層）
nginx, varnish, apache など適当なサーバーに自分でプロキシを建てて nc, telnet で通信してみればよく分かると思われる
ちなみに当職のおすすめのハッキング本は Hacking Exposure 7 ですを
ttp://www.amazon.co.uk/Hacking-Exposed-Network-Security-Solutions/dp/0071780289
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（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
newnakashima エンジニアになって楽して年収１億稼ぎたいとか思ってるカモを集めて1ヶ月でPython + Flask でサイト作らせて「これで君もエンジニアだ！（笑）」でボロ儲けしてるプログラミング教室知ってる。
簡単なフレームワークを使うのは、細かいカスタマイズやチューニングができない代わりに、HTTPなどの本質的な概念の説明に注力できるからだと思っていましたが、こういう不心得者（業者も生徒も）がいるのですねぇ。
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
