The Kinesis Advantage contoured ergonomic keyboard. Once you've used it for a few weeks, regular keyboards feel awkward and uncomfortable. They are pricy and completely worth it.
That keyboard took me 3 months to use (to be fair I was also switching to Dvorak). Luckily (?) this was while I was sidelined in a bike to car a collision. I have struggled with RSI and it really changed my life. But I agree it's not for everyone. For starters you definitely need large hands!
I had one for around 6 months and always found it frustrating to use. Eventually gritted my teeth and started to use it all the time and it's been a huge relief on my hands. Considering getting another one for home so I don't have to lug it back and forth to the office.
You may have given up prematurely. It took me a month or so to get used to it. I used the Kinesis Freestyle before, still expensive, but lasted me for years and years.
I tried to like it but returned it because it made a loud ping noise whenever a key was pressed and hit the back plate. They layout was fine but the construction just did not feel like $400.
That's hard to believe, their Dvorak/Qwerty version has four or five different keys completely mislabeled, which made me return it because I couldn't trust the product any more.
Which keys? I didn't find that to be the case -- but even if it were, one of the features of this keyboard is you can remap any of the keys to your liking.
The only thing that sucks is the rubber keys, especially ESC, especially for vim users. In contrast, having meta+ctl keys on thumbs for emacs users is huge.
Former ITA engineer here. Our airfare search product QPX was untouchable at the time due to design: it got results that were far better than those of the competitors because ITA was modeling the problem better (search through a graph). While competitor tech debt didn't hurt us, I don't think it was the pivotal factor in ITA's success. As you point out, our hopes of replacing a major carrier's reservation never came to fruition, unfortunately. A res system is a complex beast.
I do agree that QPX was untouchable, but I still think tech debt in competitors was a major factor. There were plenty of smart people at your competitors...I'm sure graph search occured to them. I suspect efforts to green field that were squashed...nobody wanted to throw out the hairball they had because of the existing investment. Thus, they tried to "fix" what they already had...with obviously bad results.
Edit: And, worth mentioning that your competitors wouldn't have had to be better than, or even as good as QPX. "Good enough" would have squashed several big sales, since shopping was typically bundled in with what their customers already paid.
React allows you to keep state in components, but that doesn't mean that you should. When you're using React + Redux, keeping ANY state in components is an antipattern. Keeping all state in the "root" (the redux store) allows you to observe the your app's complete state in one place, all previous states, and the exact sequence of events that triggered all past state transitions. This discipline enables features like time-travel debugging, where you can rewind or fast-forward through your app's states one event at a time.
Trouble with this is, if you have a lot of drop-down menus that is a tremendous amount of additional code, actions have to be added, or added with abstractions, this new thing has to be managed in the global store etc. the end result being that your app is just slower because all this info has to pass through the dispatcher :/. Also can't see how rewinding simple isolated UI effects could help in debugging.
I've noticed that when programmers are introduced to a new technique there is a tendency to apply it everywhere. I had this experience when first learning recursion, it was all I used for a while, until I realized that was silly and now only use it where appropriate. This is true for OOP, functional programming, strictly adhering to even esoteric details of REST, etc.
I've found programming to be a lot like cooking. I really liked garlic, so when I first started cooking I would routinely add a couple extra cloves, until I discovered there very much was the possibility of too much garlic. This is true for each ingredient, you try stuff out and as your experience as a chef grows, you start to be able to suss out the right amount of each ingredient added at the right time.
Programmers are essentially virtual craftsmen, you have a set of tools and you try to build something effective with the tools you have. If you adhere to a principle so fiercely, the pieces of the puzzle often don't quite fit. You end up with a circle or square where something more acorn shaped would be most appropriate.
Anyhoo, don't take my word for it: "A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson or "Only a Sith deals in absolutes" - Obi-wan.
Two responses to my comment, opposite recommendations. I'm inclined to agree with you in general, but the contradicting opinions can't be good for newcomers.
A number of people in the community seem to have latched on to this "you MUST put EVERYTHING into Redux" idea, but it's definitely _not_ anything that's pushed by the Redux team. trex654 is correct here - it's entirely up to you to decide what state should live where.
A few years ago I asked another visionary, Marvin Minsky, if he thought that, in the future, we'd do our programming in something other than plain text. He said, "If it's good enough for Aristotle and Plato, it's good enough for me."
