I avoid adding anything less than 20 years stable to my "stack".
It's proven and stable, it's bound to have a wide install base, and there is 20+ years worth of knowledge on the web for every issue I may happen to run into.
It's proven and stable, it's bound to have a wide install base, and there is 20+ years worth of knowledge on the web for every issue I may happen to run into.
Realistically the best approach for stability is to pick mature technology and that means stable, well designed and slow moving. Things like enterprise Linux distributions, Postgres, Go etc.
If your coding rules state that /every/ object with any properties needs an associated getter/setter/Builder/Factory for any code then it quickly leads to a huge amount of code and indirection to do the most trivial of tasks - made worse by the fact that Java doesn't have first-class macros.
In regards to getters and setters specifically; this stackoverflow post is quite good [1]. If those reasons don't apply then it just ends up complicating the solutions for very little benefit.
[1] https://stackoverflow.com/questions/1568091/why-use-getters-...
1. a.getFoo().getBar() vs a.foo().bar() or a.foo.bar
2. a.setFoo(1); a.setBoo(“moo”); vs a.foo(1).boo(“moo”); or a.onSomeEvent(1, “moo”);
JavaBeans are often used in reflective mapping, but nothing prevents from using simpler convention the same way.
For example, it's clear to me what setFoo() and getFoo() does, but what about foo()? Does that return the value of foo() or does it run a process called foo()?
JavaScript has a different but also unambiguous way of doing it, with a.foo used for properties, and a.foo() used for function.
foo() is neither here nor there.
Let me also quote Brian Goetz on this topic:
„No discussion involving boilerplate (or any question of Java language evolution, for that matter) can be complete without the subject of field accessors (and properties) coming up. On the one hand, accessors constitute a significant portion of the boilerplate in existing code; on the other hand, the JavaBean-style getter/setter conventions are already badly overused. Mutability may drag with it encapsulation, and encapsulation plus transparency may in turn drag accessors with them, but we should be mindful of the purpose of these accessors; it is not to abstract the representation from the API, but at most to enable rejection of bad values and provide syntactic uniformity of access. (Without rehashing the properties debate, one fundamental objection to automating JavaBean-style field accessors is that it would take what is at best a questionable -- and certainly overused -- API naming convention and burn it into the language. Unlike the core methods like Object.equals(), field accessors do not have any special treatment in the language, and so names of the form getSize() should not either. Also, while equally tedious, writing (and reading) accessor declarations are not nearly as error-prone as equals().)“
also if you did not use webforms it was basically also just a rename of using statements and impl classes between 4.7 and 2.x
Anything async is likely to be a complete pain in the ass.
It is a forum website with accounts, tagging, sorting, and moderation.
All these features are accessible to Netscape 2+ and IE3+, and also Opera 3+, Opera 12, Lynx, Links, w3m, NetSurf, Dillo, and many others, with and without JS enabled.
Accounts require cookies for now. Some enhancements require JS.
Mostly built by one dev in (copious) spare time.
My motivation is to preserve the knowledge of building compatible Web apps, to allow anyone to access my site, and to embarrass the big websites which complain if your Chrome is a couple versions behind.
I believe in aiming for 100%, not 95% accessibility, and here are some scenarios I've tested with:
* Older devices like my beloved iPads running iOS 7 and 8, which won't upgrade past that.
* Vision-impaired users with screen readers.
* Library computers stuch with IE and very old Firefox.
* Restricted access connections, browsing (and posting, and voting) via Google Translate.
* Slow connections and slow devices forced to browser without JS.
* Text-mode browsers Lynx and Links which were my only option at the time.
* Device without a keyboard available (I have several on-screen keyboards to choose from)
* Device without my keyboard layout of choice. With JS, I have two translit options at this time: phonetic-Cyrillic and Dvorak. NoJS support to come.
* Retro browsers from a long time ago with their unique beauty and features, e.g. Mosaic, IE3, Netscape, IE6, Opera 3, etc.
Some may consider these to be "edge cases" not worth a bother, at less than 0.1% of the visitors. I guess they might also consider a wheelchair ramp unnecessary, since it only gets used like once a year. I consider all these scenarios to be opportunities.
- dreamhost placeholder page
---
ps I'm really not trying to antagonize you; was genuinely curious about your claimed super-accessible website, and kept trying. Done now, have a great day and see you around HN.
The site is just a demo for hackers and friends, not for general purpose use.
HTTP Basic auth helps prevent bot crawling, which the site is not yet optimized to cope with, while being by far the most supported auth scheme from mid-90s to today.
hn has a big crowd of retro-lovers and nojs browsers.
If I'm terse and rude, I definitely get downvotes. If I'm verbose and explain my points, it's less likely, though still possible.
Most of the vulnerabilities are also JavaScript-driven, which is optional on my sites.
On the server side, of course, I use stuff which is still maintained and sometimes a multi-layer security approach.
There is no shortage of both established/mature and still-maintained tech around. Some examples I appreciate: GNU, POSIX, Linux, Perl, SQLite, PHP, Apache, Tcl.
For all of these examples there are many accessible resources with oodles of knowledge in many different convenient forms.
Newer stuff, where the main resources are Reddit and StackOverflow, and the writing is limited to just a couple of years, is nowhere near as rich or useful.
Many newer sites are also heavy and JavaScript-laden, both of which slows down access and skimming speed, if I can access them at all.
I make some exceptions, and Canvas may be one of them in the future. It's not a hard limit, more like a guideline.
I want to make stuff that lasts at least as long, and that means I should use tech that's already been around that long, to take advantage of the Lindy Effect.
I saved myself a bunch of time on a rewrite.