595 karma · joined March 12, 2013
When I used it, which admitedly was a long time ago now, the biggest setback was lack of cross device identities. So I ended up having two accounts with two feeds, `wesAtWork` and `wes`. Maybe they have solved this by now.
ps. Does patchwork still have the little gif maker? Because that was a super fun feature.
I almost always think tutorials like this make things more complicated than they need to be. Usually by including too many pieces under the "guise" that it is the "modern JavaScript stack" when many projects/companies often do not have nearly this many pieces.
Started using Beaker Browser as my main browser, DDG as my search, and am working on moving the rest of my life off google (read: gmail).
Also have been messing with doing more work on a raspi tablet rigged with a bluetooth keyboard/trackpad combo.
I just bought one the other day for personal use, pretty cheap, cant say more becuase I have yet to receive it, but I have high hopes.
Do you have a link to the issue where this was fixed/discussed? I searched for it last week and couldn't find it.
Typical Apple restricting the ecosystem. Guess we all knew what we were getting ourselves into.
Also, I believe it can be made smaller with one of the other bundlers. Browserify is not the most size conscious choice, it just happens to be the one I have the most experience with.
* ctrl-clicking to open a new tab
* shift-clicking to open a new window
* alt-clicking
* non-left-clicking
* target attribute in <a>
* mailto: in href
The solution I use[1], and disclaimer also wrote, was targeted directly at server rendered SPA's to follow closely with these ideals. Layers over native anchor tags, just barebones handles the link clicking and uses Express routing which is obviously back end compatible.
So that middleware actually requires a solution similar to what Nighthawk provides. The point was to keep the routing and the rendering separate, unlike what react router does.
I don't get it either. I thought we were over describing program behavior in XML?
My team uses this, we built it in response to most of us not liking the React Router methodology, and already using Express, it seemed like a good route.
^^ This is the one we developed on my team. No view coupling, uses industry standard underlying components (Express Router), and layers on top of existing applications seamlessly (aka, no view tie in points, just anchor tags).
The one thing we didn't do was layer on top of a flux solution. Seemed more future proof to not tie to anything other than a routing style. If you wanted to do that with our solution it would be as simple as writing an action to do the url change.
Basically it is just the Express router wrapped with logic from Page.js for catching link clicks and what not.
We do universal rendering with a simple middleware and share all our middleware, rendering and route definitions on both the FE and BE.
Of course this did mean wrapping it for use on the FE, but that was as easy as copying code form Page.js (another old school project).
We have some controversial users...
If they attackers are persistent, there is really no way to guarantee zero down time. THEY WILL FIND A WAY. Just make sure your stake holders know you are doing everything in your power to resolve the issues, and then actually do those things.
An anecdote:
We had been seeing DDOS attacks for a few weeks, so we had most everything locked down and working. But then suddenly one of the most important parts of our site started going down under load. That part is a real time chat system. We looked for which chat room had the load and it was one which did not require a user be registered. We switched the room into registered users only mode and thought we had solved it.
About 5 minutes later the attack came back with all registered users. We were amazed, becuase there is no way the attackers could have registered that many accounts in 5 minutes because of our rate limiting on that. Turns out that they had spend the past week or so registering users in case they needed them :)
We have many layers of protection:
* We run iptables and an api we wrote on our ingest servers. We run failtoban on a separate set of servers. When fail2ban sees something, we have it hit the api and add the iptables rules. This offloads the cpu of failtoban from our ingest servers.
* We block groups of known hosting company IP blocks, like digital ocean and linode. These were common sources of attacks.
* Our services all have rate limits which we throttle based on IP
* We have monitoring and auto-scaling which responds pretty quickly when needed. And has service level granularity.
* Recently moved behind cloudflare because google cloud did not protect us from attacks like the UDP floods which didn't even reach our servers.
EDIT: formatting