I think the disjoint between the audio and the visual is amplified due to the fact that the read head(s) are a couple inches to the left under the cover. So there is always a perceived delay to the audio from where you are looking. This magnifies if you for example look to the right edge of the view while it's playing a couple inches past the left, less so if you can project the last "bar" past the left edge in your mind.
This device would be better I think if the read head could be moved directly to the left edge or even perhaps placed in the center of the view. But I have a feeling it needs to be in darkness to read best.
I'm sure he understands the difference, but with two successful campaigns for the pebble, and this new one already at 2.5m, one can understand his faux pas.
I'm also sure he doesn't need us to tell him the differences between kickstarter order and a true pre-order.
I didn't pay anything extra for duty? I bought my wife a "Round" back in January, and while the Canadian dollar was crappy, I only payed 25% in CDN dollars over the websites listed price. So, not sure if I got lucky or you just didn't. :(
On a side note Canadian shoppers can find the watches at their local Best Buy... at least the current ones anyway. You might not get the style you want though, as they seem to be a bit limited that way. Pricing is usually close to the US price. I paid the extra to get the style I wanted for the wife.
One of the biggest issues for me with the Forerunner is the fact that it seems to have a rather laggy heart rate monitor. Looking at my friend heart rate tracking with the watch, shows rather abrupt increases and decreases in the heart rate, most notable at the beginning and end of a run.
Based on the cost of the Forerunner, if the new Pebble Time 2 is as accurate or better, the cost alone might have me buying it. That said I'm on Android so I would get all the benefits unlike the iOS crowd.
Are there other devices with wrist HR measuring that are appreciably better? My understanding is that if you want very precise monitoring, you're going to need a chest strap.
I'm not sure, to be honest, they all seem a bit meh, but if the Pebbles is close or better than the Forerunner it'll be worth it on price alone I feel.
A funny thing about interactive maps while driving. If I'm on my phone and I bring up a road map of the area I'm traveling and I am constantly zooming in and panning the app so that I can see locations around me then the map has failed me.
Landmarks are key to any map, but landmarks that fade in and out of focus are not all that useful. I used to be excited by the prospect of being able to bring up a map of my route and being able to see where I was going on my phone mounted to my dash. But as of late, I've been struggling to find the right zoom level that shows enough detail of the area I'm traveling while showing enough of my route.
On a number of occasions over the last year I've has to pull over and reorient myself on my map due to a failed pan/zoom attempt.
It's funny that this article came out at this time as I've been evaluating ways to mount a larger device (tablet) on my dash as maps on my phone has gotten to be rather cumbersome.
I feel that for the most part the details in this article are accurate, that the attempt by google to make the maps load quicker on mobile have compromised critical details available on the maps.
One of the key areas where this could be addressed is by loading details based on need. For example if I select a travel route between two locations, load more of the details related to that route and reduce the extras that fall outside my concern. Show me roadways that leave my target route, as well as the cities and towns along my route. Making an attempt to provide me the details I need without my need to interact with them as much as possible would be great.
yes I have had a similar experience except needing to zoom in so the Map displays a road name as not all road names are displayed when zoomed out past a certain point.
OpenStreetMap itself has no notion of layers. It has a rather simple data model for geometries and completely freeform tagging (so for example there is no technical enforcement of how a road is labeled a road in the main database). Naturally there is quite a bit of effort to use tags with clear shared meanings, but none of that happens in the database, it's the people building the editors and doing the editing that choose what the tags mean.
Consumers of OSM data generally do perform a data extraction step where the freeform tags are grouped together and perhaps normalized to some extent. So at that point you sort of start to have layers, but different apps will use different systems and rules for that step, so the layers are coming from the app maker, not from OpenStreetMap itself.
OpenStreetMap is just a database. It has no concept of layers (except the `layers=` tag used for stacking order of objects e.g. bridges). Products which use OpenStreetMap data are free to apply whatever "layer" abstractions in their UIs they like.
I just have one smallish question. Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?
In similar systems that I have constructed in the past, I have used a number of methods for passing actors in different states.
Pass a fully instantiated actor via a transfer process. Nothing changes for the actor, beyond reassigning parentage.
Pass a cleaned actor via a similar process to the bench and add process. This was used to allow an actor to be reduced to a resting state as it were. In most cases you could think of it as a resurrection method that allowed discarded actors to be reinstated with only specified base properties in place.
Anyway, I don't use Lua at all, but I like these type of actor messaging models. I look forward to reading through the rest of your documentation once it's done.
>Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?
Currently, yes. Since this is sort of an entity component system and that actors can always create more children anytime they want, I suppose I just always assumed that actors could be "spun-up" with any sort of functionality and then deleted when not used.
Benching/Joining an actor is more for handling errors at runtime or for debugging ("If I temporarily remove this actor will it solve my issue?").
"Because you only pay for the compute resources used during the migration process, a terabyte-sized database can be migrated for as little as $3."
The above is quoted from an email I received from them regarding the service this afternoon.
Note: using continuous replication and adding logging Dashboards to your links will also increase the cost. I seem to recall seeing the dashboards are $3 a piece after the first 3 or something silly like that and then data costs on top of that. My cost so far don't match that though.
I'm guess-estimating my DMS cost are going to be about $30 if the $6.48 I've spent in the last 7 days during setup and configuration time averages out.
Funny this showed up on here. I just spent the last 4-5 days playing with DMS.
My company has been using AWS for a while, but management wanted a "backup" backup off Amazon "JUST IN CASE". Due to amazon blocking replication credentials for MYSQL servers we had to basically dump over scp to our off amazon server and run the update on that machine via a script. We tried a number of different options but none were reliable. All nasty stuff.
Anyway after setting up a dms.t2.medium replication instance, I was able to create a number of tasks pulling from our amazon server to our off amazon server.(You have the option to just pull a full dump, pull a full dump and continue replication or simply replicate data.) It's been running for a little under 24 hours now and has been, solid so far with the replication. I know not even a day yet, but it's looking promising. Fingers crossed!
A small bonus to doing the setup for this. I found out the hard way that there was bad schema in our database, which I spent the last couple days fixing. DMS is rather sensitive, and will fail and not restart if it encounters to many errors trying to replicate data.
Overall cost is looking like it's going to cost me about $150 a month for the replication instance, which is only marginally more than the bandwidth costs I was incurring doing full dumps to our off amazon server.
Benefits are almost instant replication and an interface that will give me almost instant feedback on failed replication tasks, all within AWS which is where we are hosting everything else at this time. I was also able to create individualized tasks for separate schema so I can watch and manage errors on a schema by schema basis which is nice.
Overall I'm happy with it, but only time will tell if it can continue to be a reliable replication option.
Thanks for all the info. Is your On Amazon DB on RDS?
We use Postgres so it might be that we couldn't do the same. Presently I run the DB on EC2 instance(s) but one day I'm sure I'll switch to RDS. Just trying to understand what an exit strategy might look like in the future.
If the Database you want to migrate/replicate from is running on Amazon you should be able to make it a replication source.
I saw nothing that stated the database HAD to be on RDS. You use the servers address to setup the endpoints. And provide a database username and password to connect with so it should be doable.
I backed the kickstarter for this tool back when it came out and I'm glad I did. I don't do a lot of this type of thing, but overall it's the quickest and easiest one I've used! It's been a boon for making small animations for many of the quick projects I've worked on. Keep meaning to do something real and proper with it, but I've yet to take the time.
Every time I go to use it, it's getting an update and new runtimes. No complaints at all!