I've never been, but given that the tickets seem to sell out long before the list of panels/events is even posted, I'd say that Google is as much at fault as the gadget-grabbers.
I'd love to know what, exactly, I'm trying to spend a cool grand on.
324 karma · joined November 16, 2011
I'd love to know what, exactly, I'm trying to spend a cool grand on.
Granted, anything having to do with the region (imports/exports, shared upgrades, etc) was defunct.
Additionally, when you exit a city, there's a long pause where your client sends the city state to the server to be persisted (or so the UI tells me) -- another indication that the simulation is not run on the server.
My current impression is that the entire city simulation is done on the client, and the server is simply responsible for intra-city interactions and persisting game state.
--
[1] IMO, the use of wildcard certs is a dangerous practice[2] made obsolete by SNI.
[2] If the cert gets stolen from one server, the thief can impersonate any server on that domain.
alert = (args...) -> $globalMessenger().post args...
> Amazon Redshift doesn’t require indexes or materialized views and so uses less space than traditional relational database systems.
Reading through the rest of their FAQ, it sounds like they echo your conclusion -- RedShift shines the most for use-cases where the dataset is large enough that, to use PostgreSQL, you'd have to shard out multiple instances.
--
* You're measuring request latency. What part of that (for RedShift) is due to the network? (EDIT: I re-read and saw you're using `SELECT 1` as a gauge for round-trip latency and subtracting it from the results. Are you only doing this for RedShift, or also for local PostgreSQL? To me, it seems like that heuristic is over broad -- it encapsulates not only network latency, but syscall overhead, query parsing, etc).
* In your tests, PostgreSQL without indices performs on-par with RedShift. Does RedShift not support indexing? Is there some metric you're trying to show by not using indices? As designed, this benchmark does not map to any use-case I've ever seen.
I'm probably risking huge dataloss, though.
--
Native code may be runtime faster, but there's huge advantages to leveraging HTML. You'd have to either -
* Define your own serialization/markup for describing a UI, then specify a network transport for it.
* OR, just bake the whole UI in native code and fill it in with data pulled down from an API. Update the binary when you want to make UI changes.
Neither solution comes with the ease-of-development and flexibility that HTML/HTTP provide.
I would be interested to know how it actually works, because IANAL.
Normally when someone brings up git on the lists, the common response is simply, "there's already an official mirror[2]". SVN fits the FreeBSD development model -- everything is centralized.
Moreover, it can be argued that when the decision was made in 2008, DVCS's weren't as well-known as they are today. The relative maturity of SVN I believe was a large factor in the decision.
--
What prevents wrapping lightning? (I'm not at all familiar with Lightning)
> any possible gains you could expect are lost at the CGO transition
I was under the impression that the CGO overhead was due to marshaling data -- could that not be avoided by representing the JIT'd code as unsafe.Pointer's and type annotations (akin to how reflect invokes reflect.Values)? Or is there a whole realm of stuff I'm missing?
EDIT:
Did a bit of digging; reflect.Value.Call internally uses reflect·call (defined in runtime[1]), which obviously uses the Go ABI. Since any JIT'd code we want to load will expect to be called with the C ABI, presumably, we're stuck with runtime·asmcgocall[2]. Combined with runtime·cgocall[3], it certainly is longer than a vanilla preamble in C, so there's definitely some significant overhead not related to, e.g., cgo.GoString. I don't have enough prowess to determine the actual performance impact, though :(
Could be a fun weekend project.
--
[1] http://code.google.com/p/go/source/browse/src/pkg/runtime/as...
[2] http://code.google.com/p/go/source/browse/src/pkg/runtime/as...
[3] http://code.google.com/p/go/source/browse/src/pkg/runtime/cg...
Given that you're using DHCP-assigned IP addresses, you're likely behind NAT. From Google's vantage point, both employees will appear to always have the same IP address as each other.
> is it possible that a session collision happened
Looking at my browser's session state, I suspect the session cookie is SSID, which is 21 bytes. Assuming it's a base64-encoded integer, it would be a 14-byte integer. I think that would make a collision a fairly rare occurrence.
- Internal inconsistencies w.r.t formatting -- sometimes there's newlines between functions, sometimes not.
- Docstrings are fairly haphazard. I remember seeing some somewhere, but can't find them anymore. I have no idea what the `ir` module does or what it's for.
- The custom ORM (`bin/osv/`) scares the daylights out of me. It only has 4 test cases that I can see (in `test/test_osv.py`). I don't see any test cases for the DSL that the `osv` module provides.
- It appears that the ORM uses raw SQL as an intermediate for composing queries, then uses regular expressions to extract data from these intermediates.
I've only spent 10 minutes thumbing through the code, haven't read the docs or anything, so the above is a very shallow analysis.