1,000 karma · joined December 1, 2014
I barely ever click on any RSS buttons. Partially because sites nowadays don't even bother putting one in there, partially because TinyTinyRSS extracts the feed from the site's <head> automatically.
So running analytics on that button would be very misleading, especially for users like me ;-)
Just tested it and it worked flawlessly to watch a YouTube video that has been blocked in my country. [Edit: Netflix seems to block SurfEasy already. Sad.]
For NoSQL, specifically (only?) CouchDB, you start iterating from a given key (in SQL, this would effectively be "WHERE id >= $start ORDER BY id ASC LIMIT n").
This difference is why I would recommend, especially for paginated REST APIs, to provide links to the next/prev pages, so API clients can follow these links without thinking about how pagination is accomplished exactly. To prevent people from guessing the inner workings and working around your links, you can encode the parameters in a "cursor" (so instead of ?pagesize=20&page=10 you could have ?cursor=base64encode("20,10") (SQL) or ?cursor=base64encode("$startKey") (NoSQL)). IIRC Facebook does it this way. Encrypting or authenticating the cursor is IMHO overblown here, given cursor values can be easily validated and rejected if fiddled with.
Using an opaque cursor also gives you the ability to change how pagination works without breaking existing API clients.
If you plan for lots of data and many pages, think twice before outputting links to all pages (on a website) or outputting the total number of elements (in an API). COUNT(*) on InnoDB is slow and I heard it's not the quickest thing in NoSQL databases either.
I could also imagine using one window manager on remote systems and locally is just easier to remember.
Compare NPM to Composer/Packagist and you get a better comparision. I've personally seen only very few micro packages on Packagist, thankfully this never seemed to gain traction in the PHP world.
> (5A) you agree not to distribute any part of or parts of the Website or the Service, including but not limited to any Content
By downloading and sending the videos from your servers, you are distributing their content.
> (5C) you agree not to access Content through any technology or means other than the video playback pages of the Website itself, the YouTube Player, or such other means as YouTube may explicitly designate for this purpose
Downloading a video via CLI is not using the YouTube player.
> (5D) you agree not to (or attempt to) circumvent, disable or otherwise interfere with any security related features of the Service or features that (i) prevent or restrict use or copying of Content or (ii) enforce limitations on use of the Service or the content accessible via the Service
By removing ads you are interfering with the restriction that users must watch ads.
> (5L) [...] not intended to be downloaded (either permanently or temporarily), copied, stored, or redistributed by the user.
Should be obvious.
> (5M) You shall not copy, reproduce, distribute, transmit, broadcast, display, sell, license, or otherwise exploit any Content
You are copying and distributing the content.
YMMD.
I'm having high hopes for Ubuntu 16.04 having a more recent version on board. Then I will try to switch from postfix again. Because as you've said, it's really straightforward to set up :)
> AWS is hosting the public data sets at no charge for the community
Now what? What if the newspaper.com URL changes? Am I supposed to keep all my URLs up-to-date (i.e. send pull requests every now and then to update my "bookmarks")?
web.archive.org seems much more useful, by copying the entire page at the time of creating a snapshot and thereby creating a true, durable copy.
Doesn't fit the "a lot" usecase, but I wanted to at least give one real world example ;)
Gitlab CI is great if you don't need dynamically provisioned build slaves, for which I found no integrated support. In general, Gitlab CI is much more straightforward and easy to use than Jenkins.
Jenkins wins when it comes to stuff like build artifacts (getting these out of Jenkins is easy peasy (just wget them and provide basic HTTP auth if needed), but with GitLab I have not yet found a way to automatically download say the latest build results), credentials management and other "more enterprisey" features.
Jenkins is easy to install on Debian-based systems; I have no real experience in setting up Gitlab other than via the official Docker images, which is nearly as easy as typing `apt-get install jenkins`. Setting up CI runners/instances is easy as well (apt-get install + one or two calls to gitlab-multi-runner).
Overall I'm pretty happy with Gitlab CI. Especially the fact that every developer in our company can take advantage of automated builds by just enabling CI support and putting a .gitlab-ci.yml in the repository is great. Over are the days were admins had to manage Jenkins jobs.
You are clearly holding^W using it wrong. You are supposed to buy new fridges way more often, duh...</sarcasm>