It’s writing colloquially… the writer has the difficult job of describing something that’s happening inside this cabinet over time and space and other dimensions
Imposed by the game and players behavior.
Bear with us means, ‘I’m about to do a bunch of description… shore up your mental banks and prepare to reread the next bit a few times.
If you had lived through the last blackout and still lived in Texas, then absolutely yes it’s newsworthy. We want to grade our government accurately. Almost having a collapse again is a bad mark on the test score.
But we are not in a position to be focusing on custom hardware.
... a dedicated device is half the puzzle. That, and a low-latency network connection to your peers. You have those two and you can get a reliable experience.
JamKazam founder here. Happy to come across a user!
We see that too: 25ms one-way latency is the max to stay in sync, and that includes both internet + audio device encode/decode, which gets eaten up quite fast!
We are looking at providing an optional premium networking service to offer a faster connection as an alternative to the open internet. Nothing too expensive, like $10/month is the goal. Hope that gets you and your friends under that magic threshold when it's available, if you try it out.
We have a website presence too, and the website UI (as visited in a normal browser) is 95% the same style and functionality as the desktop app.
So when you browse to our site via the desktop app, certain OS-only features turn on.
So it made a bunch of sense to use QtWebkit. I welcome the switch to QWebEngine though, if for nothing else in the hopes that the underlying browser code gets a update and the app will hopefully then feel more responsive.
We have a desktop application that uses QtWebkit for the UI.
We had no choice technically-we need to use audio APIs on Win/Mac to get our job done.
Based on my experience, I would not recommend building a desktop app unless there is a technical reason to do so.
Data storage, building installers, signing your app for target OS's, and dealing with auto-update are all technical problems that I'd prefer to avoid if I could. Building cross-platform code is also a pain and, while totally doable, will slow down a team that is not familiar with it, I think.
If I really needed to build a desktop app in the future, I'd investigate building building a headless app that hosts a websocket, and use the user's browser to connect to a localhost websocket to communicate with it. (i.e., a technical choice freeing my from Qt)
Because of this, I could say, 'use the latest artifact on the develop branch', or, I could say 'use exactly master-103'. Those two alone were pretty powerful.
By the way, I asked Maven devs if this would numbering scheme would possible (at the time, I would have happily used Maven instead of Ivy because I had to build some tooling to use Ivy); they were strongly against the idea: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-curre...
Rails is still a second-class JS citizen due to the asset pipeline being opinionated and controlling compared to the node way of doing things, but it gets you closer to 'the new hotness'.
My unintuitive experience is that I remember .NET 2.0/C# syntax better than any other language, and it was because Visual Studio had the best tab-completion around (probably still does).
Perhaps because I never had to switch out to a browser (usually I could just 'tab' to the right answer), I was able to keep the code in front of my eyes and 'loaded', and somehow etch more corner-case syntax into my brain.
We use a 'monorepo', so everytime we update any gem dependency, all of our apps get rebuilt entirely. So, updating all of our packages or not isn't a problem.
And I like the duplication, believe it or not. After having debugged environmental problems with dependencies in various languages over the years, I'm happiest knowing the dependencies in question are in vendor/bundle; end of story. Sometimes, in case of a nasty bug, I have a one-liner fix and I can go to vender/bundle, tweak the gem, and know I only affected the app using it. Those are things I prefer over some lost hard drive space.
Build times are a little long for us, though. That is true. I do a fresh bundle install on every build. That is the second longest part of the build, behind running our dog slow web tests.