The one example that comes to mind is file system search.
I am writing this application that displays the file system in the browser in a GUI much like Windows Explorer or OSX Finder. It performs file system search substantially faster than Windows Explorer. Windows Explorer is written in a lower level language with decades of usage and experience where my application is a one man hobby project written in JavaScript (TypeScript).
The reason why the hobby project is so substantially faster than a piece of core technology of the flagship product of Microsoft is that it does less.
First, you have to understand how recursive tree models work. You have a general idea of how to access nodes on the tree, but you have no idea what’s there until you are close enough to touch it. File system access performance is limited by both the hardware on which the file system resides and the logic on the particular file system type. Those constraints erode away some of the performance benefits of using a lower level language. What ever operations you wish to perform must be individually applied on each node because you have no idea what’s there until you are touching it.
Second, because the operations are individually applied on each node it’s important to limit what those operations actually are. My application is only searching against a string fragment, absence of the string fragment, or a regular expression match. Wildcards are not supported and other extended search syntax is not supported. If you have to parse a rule each time before applying it to a string identifier of a node those are additional operations performed at each and every node in the designated segment of the tree.
For those familiar with the DOM in the browser it also has the same problems because it’s also a tree model. This is why querySelectors are so incredibly slow compared to walking the DOM with the boring old static DOM methods.
I don't know about private. But the largest employer in the world is the US Department of Defense employing an estimated 2.8 million people which is about triple what Amazon employs.
WalMart has about 2.2 million world wide of which 1.5 million are US employees.
Amazon, according to the article, has about 950,000 employees.
I had a tool I worked on a little bit every day for over a decade and for a while it was pretty popular with a large following. Persistence is what got me from nowhere to somewhere, but after a while persistence offers a diminishing return.
Persistence is necessary to build something from nothing to establishment. That is more than just working. It means you have pushed through into something that works well enough that other people will use it and strongly recommend it.
That is the point where a trickle becomes a flood, but the flood analogy is a bad analogy. Actual flooding, with water, is an explosive phenomenon where a large area achieves maximum saturation in unison and so the trickle becomes a serious concern almost instantly. When all water over a large area has nowhere to go suddenly at the same time there is an immediate change like the flip of a switch.
Growth and adoption don't work like that. It takes time to build adoption. By the time a product reaches critical mass many early users may have already moved on. The very thing that made your product special or unique may be gone and you probably don't know it. This means the thing that cause adoption could be code while you are still building traffic because of a lag between network effects and incentives. That means adoption could be dying while you are building traffic and you won't know and until the future once traffic catches up and begins to decline at which point you are having to catch up.
If you are passionate enough, beyond mere persistence, you will figure the traffic/adoption cycle out to keep forward momentum, but only if you are properly incentivized. It takes tremendous effort to reach a large critical mass, especially for a small team (in my case a single developer). To want to pivot past your personal motivates to keep your product alive takes something more, something different. Persistence won't buy you that.
Judging by the increase and pervasiveness of homelessness, reduced police funding, and rent increase in the city this is already done. Fortunately for Texas it is limited to just Austin.
Start up or large corporate I see that same behavior in certain technology segments. The difference is more a factor of leadership than size or establishment.
Now it's the 5th edition. I read this a decade ago when it was the second edition. I just the book and was able to then pass the test. This is a great book to learn about security even if you don't care to certify. Judging from many comments I have seen on Hacker News most software developers really have absolutely no idea what security really is. CISSP remains the industry gold standard for security.
As a front end developer your existence is ultimately defined by your grasp of very few tree models, namely the DOM but also the file system and various similar concepts when writing systems automation. It is common for developers to not grasp the concept of implicit relationships, which are a fundamental consideration of tree models.
This is basic stuff, the foundation that defines your career. And still many developers do not grasp it. They spend so much of their careers hiding from the core concepts of their jobs dependent upon abstractions to reframe the technology.
What may begin as embarrassment evolves into stubborn resolution masking extreme insecurity. Everybody can see when you are embarrassed, insecure, and when you fail to understand something. So many times people will try to redefine an important problem to appear less lost or hopeless. When other people are really listening they can see through it. It’s only a shallow self-deception.
It’s okay to not know something and need help. Pretending otherwise is poor character.
I wonder how frequently problems with children, particularly older children like teenagers, are a direct reflection of the parents’ behavior. I have trouble imagining the monumental challenge of trying to fix a child problem when the problem is the parent and the parent blaming the child for that problem.
Its complicated because people make it complicated. Instead of following trend bullshit and self-justifying tooling insanity start with the a solid foundation and build on it one tiny layer at a time.
This is a learning process. It isn't something a tool can magically do for you. If you think you can nail this in two hours or by dicking around with some tool you are lying to yourself. Don't worry, everybody with half a brain will see you for exactly what you are, so be honest with yourself that you probably aren't some software rockstar and learn to take the primitive dumb stuff very seriously.
If you are hoping a tool will magically do it for you then you will continue to suck. The web will continue to be a complicated mystery. You will probably continue to cry about how hard life is and people won't want to be around you.
At the most primitive the web is HTTP and HTML. Don't over think this. If you understand those you have the web. You don't even need URI. URI is an added convenience.
Next, build less shitty HTML. Any HTML no matter how ugly, inaccessible, presentation-oriented, user-agent centered, and otherwise broken is still a good start so long as it displays content to a web browser. The first goal of HTML is something that just works... somewhat. Improve on this. Learn to write better HTML and better content. Most people don't take HTML seriously, but this is really the most important part of building a good web experience.
Third, learn some presentation using CSS. This will take some practice. This takes some real practice. It isn't hard, and you can do really almost anything with CSS. Even still people FEAR the CSS.
Fourth, be a damn programmer and stop being afraid to read code. Learn to write JavaScript. Learn the concept of scope. Learn to really read code. A bunch of tooling and test automation isn't going to read the code for you, though many developers seem to think that is exactly what layers of unnecessary tools are for. Keep this very simple at first. Learn some basic events and then bail out. Don't immediately think you are some kind of architectural wizard, because you will fail. If you think a framework will solve this for you then continue to be mystified and confused.
Fifth, learn the DOM. The DOM is the heartbeat, or assembly language, of the client-side application experience of the web. The DOM is what binds HTML to the browser and CSS/JavaScript to HTML. Without the DOM you have a plain text experience with really bad presentation that you shouldn't be using. Frameworks won't teach you this. The best way to learn the DOM, how it really works, is to learn XML Schema. I strongly suggest this even if you never use XML or schemas ever again.
Build on that. Baby steps. It takes some effort but it isn't complicated.
You claim it’s not a matter of opinion and due to personal opinion. Weird. Then you invent a history from which to draw imaginary conclusions. It is perfectly ok to have a personal opinion on CSS. You don’t have to justify it and you certainly don’t have to conjure a dillisional alternate reality.
Imagination aside, IE3 was the first browser to offer any CSS support.
The box model issue was independent of quirks mode. Quirks mode was triggered by HTML not conformance to a modern doctype (HTML4, XHTML 1.1, or one of the three XHTML 1.0) which produced a different DOM tree and thus different layout/appearance when CSS was applied. This was particularly frustrating because even when MS fixed the corresponding CSS defects their DOM tree remained non-standard until IE9.
I remember having to deal with all these things when working with the company's aging CMS. It was a great tool, but the version the company was using was old (before standardized doctypes in 1999) and inserted a comment into the top line of code throwing all documents into quirks mode in IE.
The box model was corrected when IE released version 7, which still also featured quirks mode rendering for backwards compatibility.
I don't do that and I avoid code that does. In the days of IE7 I learned to write CSS code that was conformant to both box models. Now I just write to the standard box model. CSS isn't something that will ever be particularly challenging once you have gone through the extremes of edge case use cases.
At that time, 2001-2002, IE6 was highly praised. You don’t get to 96% marketshare by being something everybody hates. The hate came later when CSS demand ramped up and it became clear IE6 used a non-standard box model. Worse still MS essentially abandoned the browser, the result of total marketshare dominance, and tied it directly to the operating system.
The reason people are complaining about this is the lack of diversity. This has proven very bad in the past. It essentially makes the platform a proprietary space even if the dominant browser is open source. The key here is who directs the technology and direction of the platform.
Umm, no. Perhaps this is important to people who read news and need entertainment, but otherwise it is utterly relevant. In an eventual lawsuit evidence is far more important than hurt feelings.
I am writing this application that displays the file system in the browser in a GUI much like Windows Explorer or OSX Finder. It performs file system search substantially faster than Windows Explorer. Windows Explorer is written in a lower level language with decades of usage and experience where my application is a one man hobby project written in JavaScript (TypeScript).
The reason why the hobby project is so substantially faster than a piece of core technology of the flagship product of Microsoft is that it does less.
First, you have to understand how recursive tree models work. You have a general idea of how to access nodes on the tree, but you have no idea what’s there until you are close enough to touch it. File system access performance is limited by both the hardware on which the file system resides and the logic on the particular file system type. Those constraints erode away some of the performance benefits of using a lower level language. What ever operations you wish to perform must be individually applied on each node because you have no idea what’s there until you are touching it.
Second, because the operations are individually applied on each node it’s important to limit what those operations actually are. My application is only searching against a string fragment, absence of the string fragment, or a regular expression match. Wildcards are not supported and other extended search syntax is not supported. If you have to parse a rule each time before applying it to a string identifier of a node those are additional operations performed at each and every node in the designated segment of the tree.
For those familiar with the DOM in the browser it also has the same problems because it’s also a tree model. This is why querySelectors are so incredibly slow compared to walking the DOM with the boring old static DOM methods.