My take away is, all those things created throughout decades to help smoothen the process of pushing code once in a “long” while become evils in the CD world.
By “long”, it could be a day, a week, a month, or a year.
Those things include release management, feature branches, dedicated deployment team, village exercise, etc.
The right way to deal with those evils is undo it.
All the planning, meetings, approvals, tickets, politics, and general BS associated with managing “releases” will actually slow you down or kill your business in today’s world.
Go to market team can do whatever “release” they want. But engineering team should not care. In this case, a “release” should be no more than a summary of what have been gone live in the past.
Typically, you would store session data in either Redis or Memcached. But for Serverless projects, it makes sense to use hosted datastores instead—Amazon ElastiCache or DynamoDB, Google Cloud Datastore, etc.
AWS Lambda offers a convenient way to perform authentication outside of your core functions. With API Gateway’s Custom Authorizers, you can specify a separate Lambda function that is only going to take care of authenticating your users.
Still a lot of heavy-lifting. The whole point of going serverless is to focusing more on coding the business logic. 😦
Alan is very explicit about the idea of methods as goals, something you want to happen, unconcerned about how it is going to happen.
The fundamental reason behind TDD.
If we can’t find a good name, we obviously don’t know enough about either the problem domain or the solution domain.
I would suggest that you focus on class/interface names first. If you can’t find a proper name for the class, try naming functions. Look at those functions. What is keeping them together? You can apply them to… that’s the class name :-).
When Peter wrote that (1993), the idea of an Helper class was mostly unheard of. But as more people got into the OOP bandwagon, they started creating larger and larger, uncohesive classes. The proper OO thing to do, of course, is to find the right cooperating, cohesive concepts. The lazy, fake OO thing to do is to take a bunch of methods, move them outside the overblown class X, and group them in XHelper. While doing so, you often have to weaken encapsulation in some way, because XHelper needs a privileged access to X. Ouch.
Wow, I’ve never paid attention to that since helper class is so much “needed” for every project. Lol
Handler, again, is an obvious resurrection of procedural thinking. What is an handler if not a damn procedure? Why do something need to be “handled” in the first place? Oh, I know, you’re thinking of events, but even in that case, EventTarget, or even plain Target, is a much better abstraction than EventHandler.
Again, eye opening!
Still, at some point people thought it was fine to look at an interface (or at a class), see if there was some kind of “main method” or “main responsibility” (which is kinda obvious if you only have one) and name the class after that. Which is a very simple way to avoid thinking, but it’s hardly a good idea. It’s like calling a nail “Hammerable”, because you known, that’s what you do with a nail, you hammer it. It encourages procedural thinking, and leads to ineffective abstractions.
Unusual perhaps, but that’s because of the common drift toward the mechanics of things and away from concepts (because the mechanics are usually much easier to get for techies).
Sort of calling a concept IDollar instead of Currency.
A List is an IEnumerable (what??) A List is a Sequence (well, all right!)
So far, this is the best article I have read that explains and answers questions on JWT (both server and client.)
That’s why it’s also really important not to store JWT on the client, say via cookies or localstorage. Doing so you make your app vulnerable toCSRF&XSSattacks, by malicious forms or scripts to use or steal your token lying around in cookies or localstorage.
So memory only? For cookies, with HttpOnly and Secure, there should be no concern about XSS or man-in-the-middle. Yes, chance of CSRF is still there. So you need anti-forgery. For example, keeping an anti-forgery token in localstorage (since value in localstorage won’t be sent automatically with each request.)
So it really depends on the balance of security vs. cost to keep it absolutely secure.
A very good point has been made in this SO thread.
This is a painful discussion on the Internet. Our short (and opinionated answer) is that backend developers like using JWTs because a) microservices b) not needing a centralized token database.
Indeed yes, the two most important benefits.
This token is issued as part of authentication process along with the JWT. The auth server should saves this refresh token and associates it to a particular user in its own database, so that it can handle the renewing JWT logic.
The refresh token is sent by the auth server to the client as an HttpOnly cookie and is automatically sent by the browser in a /refresh_token API call.
Persisting JWT token in localstorage (prone to XSS) < Persisting JWT token in an HttpOnly cookie (prone to CSRF, a little bit better for XSS) < Persisting refresh token in an HttpOnly cookie (safe from CSRF, a little bit better for XSS).
Once your project is tens of thousands of lines of code, and several engineers work on it, our experience tells us that understanding code becomes the key to maintaining developer productivity.
Type comments were also handy for Python 2 support, which has no built-in notion of type annotations:
Azure Cosmos DB is getting more and more powerful. Now Apache Spark can be enabled. It comes with Jupyter Notebooks. You can work directly on the data. So there is no need to copy the data around. Spark worker can be auto-scaled up and down with your DB. Aggregation query performance improvement is fantastic, both faster and cost less.
E: Can chimpanzees really understand human? …we just like strange aliens. They mostly just care about other chimpanzees…if the difference is only that small, it will be really amazing. probably is much much greater.
E: We are already a cyborg. Because we are so well integrated with our phones, internet, the phone is almost like an extension of yourself. If you forgot your phone, it’s like missing limb.
J: It’s so hard to predict the future. 99.99% of the predictions that human being had about the future are all wrong…they are right by accident.
E: You can think of humanity as biological boatloader of digital super intelligence.
J: when human understand ourselves better, then we can improve the world better…but I feel what I am excited about AI is AI is to understand people, the inside of human beings.
J: …at that time, we will have a lot of jobs that nobody wants to do, so we need AI, robots to…
下面这一幕真的很搞笑。马斯克开始凝视远方，嘟哝道
E: we are gonna figure out this neuralink situation; otherwise we will be left behind…we don’t have much time. J: we don’t have much time? For what? E: we don’t have much time to solve neuralink. J: ug….（甩手并作不屑状）
E: biggest problem the world will face is population collapse (accelerating collapse).
J: I agreed.
什么原因担心人口问题，两人没有继续深入，我倒是很好奇？
J: when we love someone or something, we don’t need a reason, we just love. But we hate someone or something, there is a logic behind it. When there is a logic, AI can do better.
E: it’s a good thing that we eventually die…it’s good to have this life cycle.
Weiran's Recycle Bin 