Dirak

Networking for multiplayer games is a super interesting problem space since games tend to be more sensitive to latency, packet loss, and the accuracy of game states between clients. The problems are even more pronounced in VR where noticeable latency or artifacts can cause motion sickness.

In modern fighter games, the industry seems to be tending toward predictive lockstep networking. This is a type of networking where if the client doesn't receive the inputs of other clients from the server, it will "predict" those inputs (usually by replaying the last received input) to give the illusion of zero latency gameplay. The drawback being that you need to implement rollback in the case where the predicted input doesn't match the real received input. When poorly executed, this could look like jittery player movement with entities rubber banding and teleporting and cause artifacts, but when done properly is mostly unnoticeable.

If you're interested in this domain, I recommend checking out https://www.ggpo.net/ which is the library used in many of the modern fighter games (notably Skullgirls). It also comes with an in depth explanation of how to implement predictive networking with rollback on your own https://drive.google.com/file/d/1cV0fY8e_SC1hIFF5E1rT8XRVRzP...

> The reason why it is not "junk" is that it will teach him a bunch of important things: that you can "talk" to a computer using different languages, that those languages have different capabilities, different properties and different grammars (syntax), and that languages are all about grammar and semantics.

This would be a good point if the year where 2003. Compiling code and setting up a proper coding environment is a solved problem that isn't worth the headspace of a young and aspiring programmer. In the modern day, you can open up the console on your browser and start writing and running code just like that.

What's far more important for a beginner is to learn algorithms and data structures, which are timeless concepts that are highly valued and can be applied to any language or environment (and to give OP credit, C++ is a fine language for learning these concepts). Recursion vs iteration, control flow, data structures, time-complexity -- gaining a mastery of these topics will enable the student to write programs that make it worth while to then learn the auxiliary technologies that can make their programs usable and sharable -- unix commands, compilers, linkers, etc -- learning these tools as a means to an end.

> The correct and actually beneficial philosophy is user-tool co-evolution, that is mutual adaptation. And for this to happen, the user has to really understand their tool.

I would argue that a lot of existing technologies such as unix are less so philosophy driven and more so backwards-compatibility driven where things exist purely for historic reasons. The idiosyncrasies of say unix can be a headache for a beginner, and it'd be a better use of their time to only interact with those technologies when absolutely necessary.

Your reading of the title is grammatically correct. "written in Rust" is a modifier, and modifiers apply to the noun that comes just before it -- in this case, "existing software". The title implies that existing software written in Rust should be replaced.

Rust is a systems language, so while it is possible to build APIs with it, that's not what the language was designed for. For example, in Rust, you'll spend time thinking about memory whereas other languages will just come with GC. That being said, the developer experience and tooling for Rust is phenomenal, and some of its features such as borrow checking and lifetimes are very novel. As the language of choice for building our your API, I would recommend against Rust. But if you're into learning and exposing yourself to new things, definitely give Rust a go.

* 50% of all US currency is printed between now and the end of 2021

* 1 Bitcoin will cost over $100k on Dec 31, 2021

* An animation tool rivaling Adobe Flash for the web will emerge

* FB releases a thin virtual reality headset https://research.fb.com/blog/2020/06/holographic-optics-for-...

* Austin Tx or Seattle Wa succeeds Silicon Valley as the next major tech hub. San Francisco and its century old Victorians become the Detroit of the tech world

* Section 230 doesn't get repealed

* WFH and quarantine continues until the summer

* A React competitor that compiles to WASM with promises of perf and space gains will emerge

* A Reddit competitor emerges and wins majority marketshare

* 2021 will be the year of punk and rock n' roll

That was spectacular! I'm completely blown away by how audacious and bold the Starship project is. Sending a rocket that massive into space and then attempting to land it back on earth, with the intention of using it to eventually send people to Mars and back. Just thinking about how much force those thrusters must have been exerting to propel the ship and pull off that flip maneuver gives me chills. I can't wait to see how fast they'll take to build and send up the next one. Props to the people at SpaceX for getting this far!

A while back, the node event-stream package was compromised when the author passed ownership to a hacker. Not for money afaik: https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...

An alternative to the html model for building websites. The html model is antiquated for building web apps, and inconsistent across various browsers x platforms. The direction of the spec imo is becoming an overengineered mess that is increasingly controlled by the Google (see portals and web packages).

With the arrival of webgpu, I predict we'll begin to see end to end frameworks for building web apps that own the entire pipeline of application state management to drawing pixels on the screen.

Theres only mention of medical or health records on the page that I could find is:

"Categories of personal information:"

"Customer Records: paper and electronic customer records containing personal information, such as name, signature, [...] medical information, or health insurance information"

I would give ID the benefit of doubt here and say this just boilerplate legal text.

Post WWII, Japan was able to differentiate itself from other developing nations in becoming a major economic center precisely because it was the first to adopt American ideas such as the free market and free enterprise. A free market and a lack of regulations is what enables America today to be center for innovation when it comes to technology. Likewise, an uptick in regulation explains why car manufacturing is a stagnant industry in the US. Just to drive the point, the downfall of Detroit coincides timeline-wise closely with the city becoming a union town.

From first principles, the value gained from paying top dollar for SF based engineers is their talent and their being in the environment of SF -- the tech capital of the world. If everyone is working remote, then the environment aspect of the deal disappears and all that's left is talent correlating with salary.

Based on this assumption, I think it's actually more likely that the Staff level engineer at Twitter who moved to Kentucky for a lower cost of living will still be making the same range of salary and the SWE 1 in SF would make significantly less.

As an engineer who works on design systems for a living, I have to say I'm thoroughly impressed with Chakra UI. Its implementation is refreshingly simple and support for generally overlooked things like color theming and responsiveness is generally really well done. Props to the devs for building this -- the care and attention to detail definitely shows.

I would even take your learnings from your experience a step further and say that one should be proactive in talking to teammates and exploring ideas on how to improve the codebase if you think there is room for improvement. For instance, it may well be that inheritance is the wrong pattern for that given codebase, but there are indications that the current architecture isn't scalable.

With more investment, more research could have been put into looking at better suited architectures such as the Entity Component System architecture, where Entities such as Rects and Ellipsis are composed of units of functionality (position, resizability, etc), which is a proven architecture for this sort of application. Then, implementation would be a matter of getting team buy-in / weighing the refactor pros and cons with your team.

Tangential, but Entity Component Systems are a great way to structure systems with many types of entities that share subsets of functionalities. https://kyren.github.io/2018/09/14/rustconf-talk.html.

Contrarian opinion, but I wouldn't want to work with anyone who couldn't pass a technical screening, and I wouldn't trust any architect who couldn't implement their own designs. Wrangling APIs and knowing which technologies are hot right now don't make a senior software engineer (emphasis on engineer). Maybe at certain companies it does, but if you're building any sort of product you need to be able to DFS and BFS and sort and map from muscle memory.

So I don't understand why people think there's a disconnect between Leetcode problems and day to day work. Even in web development, the fundamental skills that Leetcode tests for come up daily. Something as simple as manipulating the DOM, for instance, requires that you know about tree data- structures and algorithms.

White-boarding challenges are--just as you said--a series of puzzles and nothing more. I also do lots of open source / make (significant) side projects, but I think it's important to be able to do these challenge problems and to be able to do them fast and to explain yourself well. I just can't respect another dev who can't reason through toy problems fast. The difference between a dev who can't toy program and one who can is the difference between a mechanic and an engineer in my opinion.

Anyway, something that has helped me get far in industry is writing detailed blog posts / post-mortems for my projects. They really help convey the fact that you know what you're doing and that you're passionate, and it's there that you can show that you have mastery of all these domain specific conecepts like `Joint Tables` and `Freshness` algorithms. You post those articles on LinkedIn and I guarantee recruiters will be all over you. Recruiters from real companies that you actually want to work for. At least that was the case for me.

This article serves as a rebuttal to http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo.... It deconstructs each criticism presented and explains why JWTs are a secure and elegant solution to authentication. It also goes over how one would go about implementing authentication securely using JWTs with Node + Express + Passport.js.

No. That's exactly wrong. We need to stop even thinking in terms of MVC. React, Vue, Angular all used component based architectures and if you think component based architectures can be labeled as MV* then you're not understanding why this pattern is lightyears better than MVC.

MVC was a hack of a pattern that developers adopted to get server side rendering architectures to even work. Good developers recognized its many flaws and when front-end development became decoupled from the server, tried and true practices and patterns such as modularity, reusability, and separation of concerns were adopted to the front end and the results of those efforts are the front end frameworks and libraries we have today. They are not variations of MVC. If you work with them as such, your SPA architecture will look just as brittle and shitty as a server-side architecture.