Anti Patterns Catalog
wiki.c2.com
wiki.c2.com
Reaching for heavy and complex tools when a straightforward solution would have sufficed.
Example: Requiring JavaScript for a simple static site. Making a wiki as an SPA.
See https://github.com/WardCunningham/remodeling#remodeling which is linked from the footer of the wiki.
That said, given that he's the original inventor of the wiki, I'd say he's earned a bit of patience on our part. Let's wait and see where he's going with these ideas (some of which are: federation, bi-directional linking between wikis, forking & merging, transclusion, etc.), a bit longer before contemplating setting up a "classic" wiki with this content.
here's a dump of the entire wiki in WikiWikiWeb markup. if you can do anything with it, let me know.
The two supported wiki markups:
- MediaWiki https://www.mediawiki.org/wiki/Help:Formatting
- TWiki http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules
I wonder which one is the closest to WikiWikiWeb syntax.
Another cool stuff would be to put that in the gopherspace.
ward's site actually contains the rules for deconstructing the JSON and translating it to HTML. I'll have a look at that when I have time.
http://bettermotherfuckingwebsite.com/
(excuse the profanity)
http://c2.com/wiki/remodel/pages/[page_title] e.g. http://c2.com/wiki/remodel/pages/AntiPatternsCatalog
What is behind the obsession with JSON?
If JSON is nested too deep, memory is exhausted.
Why blindly put an entire structure of unknown size into memory? Just to parse some text.
Why not use something like netstrings?
Well, that's technically fine. However, the page should be a static document which was rendered on the server side and the other stuff should be loaded later and only when needed.
There is no reason why the initial render can't be done in <20 KB and <5 requests.
SPAs are almost always not rendered server-side. They can be, but it's harder so they aren't.
The singleton is really just about a language trick, it hardly means anything more than a global variable fit into C++'s class hierarchy.
I've been writing C++ in the past 1.5 years. All I have saw is design patterns being used forcefully and awkwardly. And there has not been a single instance where a pattern is used and improves the overall quality.
Such practices result into closely coupled class webs, which is hostile to testing, extremely difficult to understand and change; the worst, they easily causes circular dependency, which was once considered a norm in C++ code.
They also result into overengineerred interfaces, which gradually morphed into a "DoEverything" interface, like DoEverything(ActionOptions, RuntimeEnvironment). ActionOptions literally captures every options you can have on anything; and RuntimeEnvironment includes all data for the action to happen.
IMHO, C++ code is about as good as it can be, when it manages to achieve 2 things: 1. DAG in translation unit dependency. 2. Predominantly prefer composition to inheritance.
Plus, class access control (private/protected), and anonymous namespace should not be used to hide your implementation. That makes writing tests way too troublesome. And TBH, no one wants to abuse implementation details, unless the interface is bad or no comprehensive tests.
Thorough testing of the public methods should end up calling all of the private methods. Of course, that's a best case scenario. In C++ at least, it'd be an option to make a testing class that's a friend of the class it tests. Then you could test the private members individually.
It's about encapsulation and class invariants. Public methods must preserve them, private methods can break them temporarily. You get a prepackaged component and you're prevented from introducing bugs into the component from the outside of the component.
Take std::vector, for example. By keeping implementation details (pointer to element storage and element count) private, you prevent users of the class to accidentally shoot themselves in the foot by, say, changing the element count directly.
You could use interfaces, but for that you have to use virtual functions: Objects have to be created dynamically and you have to handle pointers or references instead of values.
Also known as a function on the IO monad. The people who were writing that might have a good time with Haskell.
My question is, where is the line the line between an anti-pattern or simply a "bad practice", or if they are the same?
* Big Ball of Mud
* Creeping featuritis
* Copy Pasta
When you make a list this long, you're attempting to cast a wide net over most conditions, if not trying for total coverage by including catch-all buckets.
Meanwhile, it feels slightly impossible to ask anyone to write code at all, without having them complain about something.
The only lesson I can glean from this is that every project requires a compromise of combining abominations with idealized perfection, and that transitory human moods and emotions have more effect on programming tastes, than actual practicality.
Is it even worth having such pages in a wiki? Is this a catalog of antipatterns or empty templates?
it's still in plaintext, i.e WikiWikiWeb markup format, and I haven't touched it in a while. if anybody knows how to convert this to HTML, let me know and I'll batch-convert it.
ward, your site is taking a down-hill turn. stop with this remodeling and go back to the static site, please.