javascript:(function(){
allowCopyAndPaste = function(e){
e.stopImmediatePropagation();
return true;
};
document.addEventListener('copy', allowCopyAndPaste, true);
document.addEventListener('paste', allowCopyAndPaste, true);
document.addEventListener('onpaste', allowCopyAndPaste, true);
})();
FWIW: I (@Rondy) am not the author of the content presented here, which is an outline from Edmond Lau's book. I've just copy-pasted it from somewhere and saved as a personal gist, before it got popular on newsnews.ycombinator.com. I don't remember where exactly the original source is from and neither could find the author's name, so I cannot give him/her the proper credits.
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
| { | |
| "name": "my_vendor_name/my_package", | |
| "description": "My Package Description", | |
| "license": "GPL-3.0", | |
| "autoload": { | |
| "classmap": [ // search these directories for classes | |
| "lib/" | |
| ] | |
| }, | |
| "repositories": { |
A complete list of books, articles, blog posts, videos and neat pages that support Data Fundamentals (H), organised by Unit.
If the resource is available online (legally) I have included a link to it. Each entry has symbols following it.
- ⨕⨕⨕ indicates difficulty/depth, from ⨕ (easy to pick up intro, no background required) through ⨕⨕⨕⨕⨕ (graduate level textbook, maths heavy, expect equations)
- ⭐ indicates a particularly recommended resource; 🌟 is a very strongly recommended resource and you should look at it.
This document is an attempt to pin down all the things you don't think about when quoting for a project, and hopefully provide a starting point for some kind of framework to make quoting, working and delivering small-medium jobs more predictable and less stressful.
The hardest bit of any job, and lots of pitfalls
Estimating the work
- the actual work of what you see on screen will only be a fraction of the work to do
The big "make everything stateless" hype is just that: hype. Your server-side application code, should usually be stateless, because this makes your application more resilient to errors, easier to scale, and easier to reason about. But there are exceptions to even that, especially for stuff like video game servers.
Your services are almost always going to be stateful, and should be. If you have a database, files, or literally anything that affects the responses the server sends, then the service is not stateless.
So building "stateless" services is a lie. You shouldn't strive to make your services stateless, you should make sure you're putting your state in the correct place.
TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.
If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)
A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/
The reason to avoid JWTs comes down to a couple different points:
- The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
2020/5/31追記:
自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。
と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。
このドキュメントを完成させるために、今後以下のような更新を予定しています。
- TODO部分を埋める
- 書籍を基にした理論・原則パートと、実装例パートを分割
- 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。
2021/1/22追記: