reipahb

It has already been disabled by default for a while. From the article:

> The query cache has been disabled-by-default since MySQL 5.6 (2013)

Isn't that what deploy keys are for? See: http://docs.gitlab.com/ce/ssh/README.html#deploy-keys

Deploy keys give read-only access to clone a repository, and they are associated directly with the repository.

The difference is that the last one also matches requests to "/", while the regex ensures that there is at least a single character after the "/".

That allows "/" to be used for other purposes, e.g. redirecting to the main page of the site, or displaying a nice error page. (However, in this case it simply shows the default Debian Nginx installation page: http://m.charlesleifer.com/ )

This being Amazon AWS gives me hope that this will be a CA with an API that allows automatic certificate issuance for domains you control. I find the process of issuing and reissuing certificates for all sorts of services to be an increasing amount of work as more and more services move to https.

(The letsencrypt.org CA is build around automated certificate issuance through an API, but some competition wouldn't be a bad thing.)

For people interested in redesigning how web site authentication is performed, I would encourage a look at the FIDO Alliance specifications for "Passwordless UX" and "Second Factor UX":

https://fidoalliance.org/specifications/overview/

The problem with redesigning how web site authentication is performed is always that it requires support (or at least extensions) in the browser the user is using, as well as in the websites the user is logging into.

Both Microsoft and Google are members of the FIDO Alliance, so maybe these specifications may actually go somewhere. (Sadly, Apple is absent from the member list.)

I don't think programming languages implement decorators in order to facilitate type checking. They implement decorators because they are a nice generic way to reuse code in many functions / classes.

Now, once you have support for decorators, they can obviously be reused for type checking, but the linked repository also contains a few more decorators such as a memoization decorator.

I think those that add type checking decorators do so because it is a convenient way to add a some common code to multiple functions. The alternative for those that add decorators is to manually add a set of type checks in the beginning of each function.

Of course, if the language supported type checking they would simply use that, but if not, this is a simple way to save some lines of code.

For those looking for more details about what has changed, the changelog is here:

https://hg.python.org/cpython/raw-file/v2.7.10/Misc/NEWS

(Unfortunately, there doesn't appear to be a short summary of the most important changes/bugfixes, like there have been for some of the earlier releases.)

An alternative solution to a viewbox property would be to use CSS transforms. It is a bit harder to work with, since you have to specify translation and scale instead of simply specifying the bounding box, but I don't think it is unreasonably hard.

See for example: https://jsfiddle.net/kuvodbax/1/

However (almost?) all syscalls dealing with filesystem paths take null-terminated strings. See for example the implementation of the open() syscall:

https://github.com/torvalds/linux/blob/fb65d872d7a8dc629837a...

(Hence the need for the strncpy_from_user()-function: https://github.com/torvalds/linux/blob/fb65d872d7a8dc629837a...)

I agree that arbitrary limits can be a bit restrictive at times, but that is mostly an issue when dealing with automated code checking tools.

However, in this case it is more about something to keep an eye for for the reviewer -- if the function is large and complicated it may be a good idea to take a closer look at it. Presumably the reviewer won't force the function to be broken into smaller pieces unless it actually improves readability and maintainability of the code.

Personally, I would really like to see more Python extensions written using the ctypes foreign function library. This has two advantages:

* Supported on more than just CPython. I.e. you can use them on PyPy as well.

* The extensions are far easier to install, since one doesn't need both a full C compiler as well as all development headers for the library installed on the server where you install the extension.

Actually, deleted orders are not a problem with continuation tokens. The deleted order is only an issue if you use traditional paging requests, which was the point of the article.

The only case I can currently think of that cannot be solved using continuation tokens sent to the client is where the order of the items that are enumerated may change between calls to the API. For example, imagine that you are fetching items sorted by score, and somebody upvotes or downvotes an item while you are enumerating them. In that case it is very difficult to encode enough information in the continuation token. (I can think of complicated ways to make it work, but the resulting database queries would be horrible.)

But for simple stuff like deleted items and similar, it is easy. If you leave out sorting it is trivial to implement as well -- all you need is to enumerate the items based on an internal ID that is guaranteed to always increase, filtering them as required. The continuation token will simply be the ID of the last item you evaluated and the filter that is applied. On the next request you just resume from that ID. If that item ID happens to be deleted in the meantime it is no problem. You just resume from the next one available. I.e.:

  SELECT * FROM items WHERE id > :last_returned_id AND [insert-filter-here] ORDER BY id LIMIT 100;

I don't think this requires storing anything on the server. That was kind of the point of the whole "store the server state in the continuation token"-thing :)

You want to store enough information in the token that you can easily reconstruct and resume the enumeration.

For example, let us say that the user asked for all comments with a score >= 5 sorted by post time. In that case you could return 100 comments, and a token that encoded something like:

  {
    "min_score": 5,
    "sort": "post_time",
    "resume_from_post_time": "2015-05-07T05:34:02Z",
  }

To ensure that it is easy to resume the enumeration, the API can fudge the number of returned items so that the returned data always breaks at a nice "post_time" boundary. The goal here is to make it easy for the client to get all the data in the enumeration without implementing all this logic themselves.

True, it will only work efficiently for some types of queries, but a lot of the common queries can be reworked into something like that.

Actually, what you get when referencing x.test in Python is a bound method:

  >>> foo.test
  <unbound method foo.test>
  >>> x.test
  <bound method foo.test of <__main__.foo instance at 0xf74d68ac>>
  >>> z = x.test
  >>> z(123)
  <__main__.foo instance at 0xf74d68ac> 123

I really like this behavior in Python. Unfortunately, JavaScript does not behave the same way, as you see in the last couple of lines in your example. You can however get the same result by manually binding the method to the object:

  z = x.test.bind(x)
  // z is: function () { [native code] }
  z(123)
  // foo {test: function} 123

The only way I see to solve this without server side state is to replace the page-parameter with a list of items you have seen. The more button would then just find the top 30 items you haven't previously seen. Unfortunately, this would become unwieldy very quickly, and sooner or later you hit the browser limitations on maximum URL size.

A relatively simple approach that involves server side state is to periodically (once a minute?) generate the list of (for example) the 10000 top items.

(A high traffic site will most likely want to do this in any case, so that it has a cached list of items ready to serve to clients, instead of issuing a database query to find the top items for every request.)

Now, instead of overwriting the list of top items every time you regenerate it, keep multiple versions of the list. Then you can make the link to the next page specify the version of the list and the page number. That way, users will browse through one specific version of the list.

(This requires storing some state on the server, but the amount is relatively small. You control both the size of the generated list, how often new lists are generated and how long they are kept, so there is an easily calculated upper bound on the amount of state information you need store.)

One thing to note is that while the continuation token is just a blob of data from the clients perspective, the server can actually use it to store the required state information.

A simple method would be to take the state information the server needs in order to continue the enumeration (e.g. sorting order, how far along it was in the enumeration, etc.), JSON-encode it, encrypt&sign it, and then base64 encode it.

Return that token to the client, and if the client wants more data it can pass that token back to the server, which can decode it into all the information it needs to resume the enumeration.