In another comment I mention how overwhelmed I am by all this stuff, so maybe don't take it from me, but when I've been searching for answers about stuff like best practices for windows or replacing my furnace with a heat pump, greenbuildingadvisor.com seems to come up a lot and seems pretty good. That said, much of it is behind a paywall that's quite expensive, and I've been waiting to save my free trial for the optimal moment.
> Sometimes making the cinematics wasn't a core competence of the studio working on the game, so VFX or animation studios would be contracted to do this.
That explains why FFX's cinematics had different character models compared to in-game designs.
What I've been annoyed with for years: Drying Racks.
What do people do instead of using these? I'm guess just hand drying them. I do have a lot of air-tight container lids that are super annoying to hand dry.
I like the convenience of the drying rack, but hate the countertop clutter and space it takes.
In Finland the drying cupboard is a standard thing in most homes. Its placed over the sink so the water drops into the sink or the metal counter top around the sink. Drying and storage at the same time. Quite handy.
See https://www.thekitchn.com/finnish-dish-drying-cabinet-for-ea...
I fill the washer during the day. Turn it on in the evening. Let it run (I use a 30 min program).
Then, before going to bed, I open the machine wide open, pull out the "drawers" and let the dishes dry through the night before emptying the machine in the morning.
Of course this won't work, if you wash dishes by hand. If that's the case, a drying cabinet may be the solution for you.
I got a dish rack that goes over my sink so I can reclaim the counter space that was used by the drying rack. The water drips down into the sink. The main draw back is I am afraid to put anything too heavy in it, like a Dutch oven, so those get hand dried. As a single in a studio apartment it keeps my minimal counter space clear.
Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc.
Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an issue anymore. Rendering a bunch of HTML is as quick as rendering JSON.
As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.
Not quite what I remember. XMLHttpRequest was invented by Microsoft and used in a outlook webaccess. This was only possible in IE6.
But Ajax is merely a pattern that was enabled by the ‘dynamic html’ that was made possible by having a DOM and JavaScript. It was possible in Netscape years before IE6. I did a production app with Ajax in 1999, using IE4. Before the term Ajax had been coined.
AJAX in early Gmail was a massive improvement. It was mostly hand-coded javascript in a relatively thin page and it was the sweep spot. Today's version of gmail is the most bloated pile of spaghetti framework code imaginable and is far less responsive and usable than the plain HTML version.
SPAs were a workaround to slow CPU servers serving millions of requests in the mind-2000s. Client computers were faster, so it made sense to push UX logic there.
We've flipped things around. Servers are fast as hell for rendering HTMl. We can leverage that and re-focus the client on UI code that only it can do.
You should definitely request this feature via their customer support or similar. I've found small companies are often love hearing from their users and are quite responsive to these kind of requests.
I also switched from paprika to PlanToEat, and in general like it, however, they never respond to emails in the usual ways, so it feels like a black hole sending bug reports or feature requests.
They would usually fix bugs a few months later, so I do presume someone is reading the email, but yeah, expect silence if you do reach out.
That said, I’m still happy enough to recommend using them.
Haven't tried PtE, may give it a go at some point.
But just mentioning Paprika does indeed allow you to populate your shopping list from your meal plan, or from an individual recipe. I use this feature frequently.
The bar to writing javascript is so much lower compared to other languages. All you need is a browser and learn how to open its devtools. Beyond that, you need a text editor, learn basic HTML and JS, and open a file in your browser.
Compare that to other languages, where you need to open a terminal or install special software, figure out how to write commands, install these things called packages, get esoteric errors, etc.
That amount of work to write JS vs other languages is drastically different for new coders.
With this lower bar comes a larger user base. A larger user base leads to more innovation – for better or worse.
It's inevitable to see people reinventing the wheel as they learn, simplified tools targeted at niche users, different needs (high-scale engineers vs designers), etc.
I know engineering communities get exhausted by the library churn of the JS community, but I think it's a symptom of real success. A user base this large is going to create noise, but also produce real gems from time to time.
This makes it sound like the low skilled people are the ones changing the ecosystem so much. The developers behind the projects that change the ecosystem are extremely talented and would be proficient in any other language as well.
I think the main reason is JS is by far where most engineering hours in the industry is spent and this makes many smart minds think about possible improvements. People don't get in to JS because its easier than others, they do because it is the language that is required the most for a typical tech company and those job spots need to be filled.
Perhaps the attraction has to do with the large end user base more than its lower barrier of entry for devs.
Javascript is the one language you can learn and easily deploy anywhere... web, apps, server, etc. This attracts a lot of new devs and the ecosystem tries to fix inherent language limitations with new tools. i.e. It's not the best language to write an app in but you can make it work with a lot of extra tooling. But then the tooling will need to keep evolving to try to keep shrinking the pain points and limitations of the language itself.
Another huge factor is how fast browser and Node standards and APIs change, making older tooling redundant or obsolete. e.g. jQuery isn't really needed as a polyfill in browsers anymore.
> I know engineering communities get exhausted by the library churn of the JS community, but I think it's a symptom of real success. A user base this large is going to create noise, but also produce real gems from time to time.
I wonder why this wasn't quite the case with something like PHP, then. It had (and in some respects still has) an enormous userbase, the technology had good enough performance, had batteries included for the most common use cases and was also relatively easy to get started with (being not too dissimilar to the CGI approach of having a request and a response, unlike the Java servlet mess at that time).
And yet, Apart from projects like WordPress, Symfony, Laravel and maybe a few others, it feels like it didn't ever get quite as popular, at least from a project/tooling perspective. I mean, XAMPP was nice and the entire LAMP stack worked well for typical configurations but things just kind of stalled there, maybe as other options came along.
PHP doesn't run in browsers. Nor does anything that's not vanilla JS. That's why everything else either transpires to JS or requires hoop jumps like WASM.
Until that changes JS will be the least worst option for folks who need unbounded browser interactivity.
Everyone recommends The Manager's Path, but I don't think it's a good book to explain HOW to become a manager. The book's goal is to explain the career path of a manager from tech lead to CTO.
My #1 recommendation these days is "Become an Effective Software Engineering Manager" by Jamies Stanier. This book explains how to approach the work a manager is involved in and what you can expect from the day to day. Planning, hard conversations, performance reviews etc.
Also, look for general management books. Leadership is something all humans do – software management is about managing creative people. Some other books I recommend are:
• Creativity, Inc by Ed Matmull
• Crucial Conversation
• Team of Teams
Lastly, I also write a blog called Build the Stage (https://www.buildthestage.com) about managing SWEs. I've got posts about performance reviews, team meetings, how to give feedback, etc. It'll help you out.
Stanier's book should be required reading for anyone becoming a people manager for the first time. I cannot recommend it enough and regularly give it to new or aspiring managers.
Yep, I really like sports related books too, such as Eleven Rings: The Soul of Success, and Leading: Learning from Life and My Years at Manchester United
What's wrong with it? I'm just gathering recommendations myself, and it'd help to know especially if there are more general red flags to watch out for.
The book is completely fine and worth the read! Just know that it's a book to explain the career path of an Engineering Manager in the tech industry.
My criticism is around how often the book is recommended. Many people want to learn HOW to become a manager. Manager's Path doesn't provide that.
Conversely, a lot of people recommend An Elegant Puzzle. Great book, but I would not recommend it to first time managers – it's too advanced.
Elegant Puzzle is for experienced managers, specifically people that are managing Managers. Check it out if you're 2+ years into their management career.
When I write the tests first, it gives me a feel for how consumers of the API will use it. It's a great method to understand the UX of the re-usable code.
The only one I've found is https://inspectapedia.com
There's great stuff on YouTube too (e.g. Matt Risinger's channel), but soooo much conflicting information.