I went a similar route (Postgres for CRUD and Elastic for searching) and also underestimated the effort of keeping the two datastore in sync as well as underestimated the effort in maintaining a reliable Elastic cluster with limited manpower/experience. After moving to Postgres full text search with indexes and query boosting, I accomplished everything I needed inside Postgres with update triggers and search queries that were incredibly performant.
The documentation that Microsoft puts out regarding its "multi-master" features basically advises against using "multi-master" mode and leveraging the Flexible Single Master Operation (FSMO) Roles to ensure consistency across the domain and forest because its conflict resolution is not comprehensive [1]. FSMO roles were created decades ago as a transition from Windows NT's Primary Domain Controller (PDC) model to avoid some of these complexities around changes in a large distributed system. Its a decent solution that has its own pros/cons, but AD is not something I would use as a good example of a multi-master distributed database.
Can you please expand on this a bit more? I live in Colorado and saw virtually no change when looking for a new job inside and outside of the state last year. I did run across a few "no job applications from CO" as was mentioned in other comment threads, but most job postings I saw did not post salary information.
I see your points and understand the frustration. The minor changes over the years haven't bothered me too much. What really messed with me was when the commit pop-up (with diffs) was changed to a tab, nestled in the same space as my files. Nooooooooo! I want the pop-up. I want to know that this is different from what I was doing before.
I have had similar experiences, however, it's important to be specific: the NMCI contract ended in 2010 and DoN moved to the Continuity of Services Contract where we bought services piecemeal until we could fully take it over. The Navy and Marine Corps tried to transition to NGEN during this time but mostly failed and each service ended up taking different paths. Now, the two services operate their networks differently: the Marine Corps, for example, runs it as a government owned and "shared operations" model where it's mixed government and contractor.
I imagine that the laptop you were given in 2018 was not an NMCI laptop, but instead a laptop from either the Navy or Marine Corps' new ownership/operations model which is incredibly flawed. Also, HBSS was poorly implemented in the 2010 time frame and Tanium was introduced (at least in the Marine Corps networks) around 2017. Both are major contributing factors to the issue you're describing.
In short: the current state is that computers are barely usable and that is not NMCI from yester-year.
I agree that military IT has been atrocious. I disagree that NMCI was "damn near treasonous levels of awful." NMCI was a large, Department of the Navy (DoN) -wide contract that had incredibly challenging tasks it needed to complete to be successful. The first few years were bad but it got better over time and, by the time the next transition was set to happen, it was running pretty smoothly.
When people complained about not getting the things they wanted, what they were really railing against was the fact that they didn't get what they wanted all the time anymore; the military grew accustomed to telling someone "I want X" and it happened, regardless of cost, lifecycle sustainment, security, etc. NMCI forced the DoN to develop and articulate requirements properly, write good contracts, budget for software and hardware sustainment, and generally operate professionally.
In short, I would take an NMCI computer and enterprise services from 2010 versus a Marine Corps Enterprise Network computer and enterprise services from 2022 any day of the week.
Disclosure: I have been a Marine Corps Communications Officer for almost 20 years; starting before NMCI. I worked at the regional and enterprise levels to transition ownership back from the NMCI program/contractor to government owned.
OP here. This find was a tiny joy in my day. The article was from 1998 and the page appears to be untouched by all the "upgrades" in HTML. I love this...image maps, light HTML, tables...oh my!
Many of the ski resort companies do offer housing, which is great. There are two primary issues with that at the moment: not enough housing and, the bigger one, when your housing is directly tied to your job what happens if you are fired? Colorado, for example, is an "at will" state--that means someone can be let go for any or no reason with no notice. If the company is providing housing, then the person is forced to up and move...but where do they move to?
My partner has lived in Crested Butte for 18 years and I just came back from a weekend there. Restaurant prices are already high and each one has "help wanted" signs out front because nobody can work for minimum wage and not even afford to live there. Raising prices of a $20 cocktail to $25 does not allow the restaurant to pay hourly, local workers enough money to afford a house that's over $800k or rent that's over $2k/mo. The numbers just plain don't add up.
It would be very interesting to see a consumer-oriented ARM SoC from one of the other main manufacturers. I doubt that will happen, however. Their entire business is based on being a component in a chain of components, not being the entire thing. Although, for example, Intel makes some motherboards, some GPUs, etc...their business isn't based on putting it all together in one fabric for their end-clients. They'd have to control/influence more of the OS for that. Apple has it all: full hardware control, full software control, and it's all designed for the mass market consumer.
I disagree with this perspective. I think it's important to recognize that the M1 is a System on a Chip (SoC), not simply a CPU. Comparing the Apple M1 to "mid-range 8-core AMD desktop CPUs from 2020" is not comparing apples to apples. The M1 Max in the Geek Bench score has 10 cores whereas the AMD desktop CPUs you mention have 8-cores. That would be more of an apples to apples comparison.
Where the M1 architecture really shines is the collaboration between CPU, GPU, memory, SSD, and other components on the SoC. The components all work together within the same 5nm silicon fabric, without ever having to go out to electrical interconnects on a motherboard. Thereby saving power, heat, etc.
What you lose in repairability/upgradability, you gain in performance on every front. That tradeoff is no different than what we chose in our mobile devices. If repairability and upgradability are more important to you, then definitely don't buy a device with an Apple M1; absolutely buy a Framework laptop (https://frame.work).
Be curious; learn it. Figure out pros/cons for yourself. You'll have more breadth of knowledge, more depth in specific areas, and will likely make better architecture choices in the future because of it.
Read @leerob's answer first. Additionally, the notion of "forcing" CSR might be a misnomer. The way I understand it, NextJS always prefers CSR; the server renders HTML on first page load and the NextJS framework attaches JS stuff to the page on render to handle the client-side interactivity. So, if you turn off JS on your browser and load the page, everything works out of the box (page renders HTML, links work, etc). There are ways to specify server-only data requirements.
Once the client-side JS has taken over, the `next/link` component [1] is used to render and listen to events when a user clicks on a link. That component tells `next/router` to render the page that was clicked on. All of this happens on the client by default. If JS is disabled on the client, then the HTML rendered by the `next/link` component on the server is a simple `<a/>` tag and a normal browser page load occurs.
Yes, NextJS does the same. After re-reading my comment, I don't think I was clear: our reasons for moving to NextJS were the two mentioned, not because it was less complicated than our Webpack config from 7 years ago. It's not less complicated, it's different. NextJS does some weird things under the hood to make it seamless (like CRA does) but it can make things even more complicated to go with nonstandard Webpack rules or Babel presets/plugins. Overall, I think any JS application written in this day and age is going to be a tooling nightmare--NextJS included. In our case, it's not bad enough to force us away from JS (or TypeScript) yet.
Not the OP nor the post's author. We have a similar stack (React + NextJS + TypeScript + Mobx) but use a traditional REST API using Django Rest Framework. There are some interesting topics in the post and in these comments that I figured I could expand on:
1. The primary reason we chose NextJS (with SSR) was to be able to write a declarative React component that is run on the server and the client. For example a button to follow or unfollow a page (think: like/unlike in social media). In the previous generation of our application, we wrote the button in PHP that rendered HTML and toggled UI state on the front end using JS/jQuery. That meant writing the button logic (and HTML/CSS) in two places instead of one. Now, we have a single React component that renders itself based on state; it's the same component on the server and client.
2. I don't understand the extra work to avoid SSR. SSR is great and can be used behind authentication--there's no actual need to work around it. Additionally, in a NextJS application, SSR is only used on the first page load. When you click from page to page, it's all client-side transitions.
3. @yashap said "The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack." Agreed. Same here. It's wonderful. In particular Mobx. A lot of the comments seem to say "I expected the article to talk about how to maintain state in a React application"--that's how. Use Mobx. No matter what reactive JS framework you're using, use Mobx to maintain "global" state.
4. The discussion of "why move to NextJS when my Webpack config from 6 years ago works just fine" is a good one. Two big reasons we moved to NextJS (away from a Webpack config from 7 years ago) were: the handoff from server -> client is more seamless and the developer experience with hot module reload for server + client sides was worth it. Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense.