I switched to Newsblur after the shutdown of Google Reader. It's paid, but after what happened with Reader I realized how important a good RSS feed was to me and that it was worth paying for. The cost is also reasonable.
What is your reasoning for not using query params for the login request? I know it's probably more RESTful to use POST, but otherwise if you're using HTTPS for everything, query params are just as encrypted as the POST body. Or is there another reason?
For one, the query string is much more likely to be logged, compared to the entity body. Think: httpd access logs, browser history, misconfigured caches / correctly configured caches subject to inappropriate cache directives, etc.
GET requests just do not make sense for actions: they are cacheable and replayable. An http client/a proxy/something on the backend can cache it and avoid going to the actual logic.
Also, mixing credentials into URL does not feel like a good separation of concerns, e.g. URLs are often logged and analyzed in separate logging/monitoring/analytic tools, so there is a bigger risk to have credentials leaked over some side-channel.
I feel the same way. Headspace's guided take 10 course was a solid introduction for me, but once I got used to regular practice, headspace's "extras" weren't needed anymore. Now all I really want is a timer and tracking of when I meditated, so I use Insight Timer.
Banning smartphones doesn't preclude having dumb cell phones. My smartphone died last week and I thought long and hard about getting another one. Ultimately I don't have the willpower to totally resist, but these last few days without one have been enlightening.
I used last year to learn Elm really well and plan on using this year for F#. Go for it!
Elm served as a gentle intro to Haskell for me personally since it has easier to read errors and less overall complexity to grok at first go, but it sort of depends on your experience.
I've had quite the opposite experience. Vagrant has saved my team lots of time fighting environmental issues. The approach of running apache locally falls apart pretty quickly as you add more components to your application. Elastic search, mongo, one person happens to have php 7 instead of 5.2 and wrote everything with short array syntax, etc.
We also work on many different projects, often getting dropped into something new without much of a primer. Being able to "vagrant up" and not having to know all the dependencies to get up and running is very handy.
Do we spend time troubleshooting vagrant weirdness? For sure, but compared to the time saved it's a no-brainer.
I tend to agree with the parent comment, a small team can get away without it if the software stack is stable. PHP 5.2 to 7 is quite a change and should have been documented upfront. I assume that the project must conform to certain software requirements. On the other hand, npm is full of surprises.
I don't disagree that if you can get away with just a local development environment that it is likely easier to get up and running. However, it requires good documentation of project dependencies and discipline by the team to not accidentally upgrade their version of PHP without telling anyone, both things that are easier said than done. Vagrant lets you codify that through "code". In the case of my employer, it's a necessity, but obviously everyone is different.
I've been running Nightly and experienced the same thing with inbox. If I attempt to interact with it before fully loaded, inbox will freeze up for minutes at a time. Love everything else about nightly, this is my biggest issue.
Seriously, when we talk so much about the Web's portability, why is a major feature from a major website not even working on identically on the two biggest browsers? Since it's Facebook we can't accuse them of browser favouritism as they're browser neutral. I wonder what APIs are missing from Firefox that makes FB Live Video broken?
> Favoritism isn't the only reason for these things. What often happens is that the website devs all use one browser and nobody tests it.
That is exactly the point the GP post makes. These things are supposed to be standardized and the standards well described, so basic things should work everywhere without any testing. But somehow for web, it is acceptable and accepted as status quo, even after years and years of smashing our heads against the wall of nonstandard, browser-specific features.
Yeah. Well, it's not just "features", it's also stuff like minor differences that the spec allows for (the spec doesn't spec everything). For example, assuming the order of elements in the indexed getter of getComputedValues().
There are also cases like where Google's U2F library doesn't work with Firefox's U2F implementation because Firefox's window.u2f is immutable, as a newer (IIRC draft) spec dictates, whereas it isn't in Chrome, and the library does `var u2f=u2f||{}` which errors in Firefox.
Works in Nightly but the video quality is beyond garbage. 1080p webcam should not look like 320p. Chrome properly sees my camera resolution and uses it.
Same experience here! I had never seen them, but when we had our daughter my aunt wisely gave us barnyard dance. I was skeptical at first, but the collection of boynton has grown and is still very popular at 18 months.
Doggies is a fun read for onlookers, since it's basically dad or mom making dog noises for 15 minutes straight.
IMO you don't need a reason for something like this, it's just fun. We all spend a lot of time solving problems with software and I believe most of us neglect that you can make stuff just to make stuff. I wrote an angular directive that prints out ascii butts: https://www.npmjs.com/package/pw-butts, I doubt anyone will use it for anything, but I enjoyed making it and it's fun that it exists. If it helps, think of it as "Art".
