ownedthx

The numerical issues here are due to JavaScript, not JSON.

‘The Manor on Stagecoach’

https://g.co/kgs/tgHhdkD

You aren’t alone

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.

Man

Amish furniture is built extremely well. And the price is not cheap but not exhorbiant. And clearly American made :)

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.

wince

We need to take that section/link down.

We did do a KickStarter for the JamBlaster, made ~200 and shipped them.

https://www.kickstarter.com/projects/1091884999/jamblaster-t...

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.

My all time favorite theory: http://pbfcomics.com/comics/dinosaur-meteors/

Get them out of the house. It's the same quitting unhealthy food. Take away easy access, and you'll do something else.

The frontend is all HTML inside of the webview.

We do have a tray icon too, though.

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.

Thanks!

Mind sharing your stack?

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)

Antecdata: most of the scamming directed towards our startup comes from Tor exit nodes.

Annecdote time.

My back has hurt for about 15 years, since the age of 18.

I didn't exercise reguraly during that time.

I haven't had any pain for the past 2 years... The change us definitely tied to this: I started working out reguraly (HIIT style in my case).

A scheme I settled on a previous job that I really liked for internal apps was:

branch-buildno

Where branch is the git branch, and buildno came from our build machine (Jenkins in our case).

examples:

* develop-5

* master-10

I then used this ivy-based project: https://github.com/sethcall/depends to push those dependencies to our own internal artifact repository.

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...

I'm not sure if this is baked into Rails 5, but you can get es6 support (via Babel) with the sprockets-es6 gem:

https://github.com/TannerRogalsky/sprockets-es6

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.

Valid points.

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.

As someone who deploys Ruby software to our servers, I've come up with a formula that's served us well.

We take all gems associated with the app (like a Rails app, but we do it with others), and stuff them along with the code into a package created by fpm.

In other words, the packages are completely self-contained; no gems are used from the environment.

The key to this is the --path option to bundle install, i.e.:

bundle install --path vendor/bundle

This command makes sure all my gems are in a sub directory of my project called vendor/bundle. When creating the debian package using fpm which includes all the source code, vendor/bundle also comes along with the package.

After installing the app on our Linux servers, 'bundle exec rails server' uses the gems from vendor/bundle.

This approach does require that I create the debian package on a machine that closely mirrors the deployed servers, so that compiled gems make any sense.

Most all the issues described in the article have not been problems because of this approach. I used to use rvm as part of my build process; it was very brittle. I'm completely happy now; just wanted to share in case that helps someone else.

Seemingly a good list; http://fluoridealert.org/content/communities/

Since there are US cities like Texarkana, AR that have not have fluoride in the water ever, it seems they would be a decent way to harvest some data quickly and get to the bottom of this.

Anecdotally, I know a dentist that would work 2 days a week there as a sort of 'import-a-dentist' program, and she thought teeth were, in general, in much worse shape there than Little Rock, AR (3 hours away). Not enough to go on obviously.

http://www.jamkazam.com - we are not yet VC-backed, but I hope so soon.

Because latency is an absolute premium for playing music in real-time across the internet, we've focused first on the desktop, where we have the most control ... but still find a ton of challenges.

If you saw this recent article about Android and audio latency, you can see why there are challenges in the mobile space: https://news.ycombinator.com/item?id=9386994

If you were to try and build a web-only version of JamKazam, WebRTC is your best bet but it does not have low enough latency, either.

You raise a good point, but for me it only solidifies the fact that it is a view point born from inexperience or narrow experience. If you only have a bunch of .NET experience, or if you only have a bunch of Node experience, it isn't surprising when you judge others poorly when they don't like the sane OS as you do. Age and more experience will cure that.

Read about things, and use things, and you will find out about what's missing from those things (and therefore what people want).

At JamKazam, we are trying to enable real-time play of music over the internet. While we can't magically make the internet better, we have spent a ton of time getting latency as low as we can in Windows, Mac OSX, Linux, and on custom hardware (still under development).

Just a week ago we released our 'distributed metronome', which lets musicians hear a synchronized metronome regardless of how much internet latency there might be.

Replace DevOps with QA and an equally valid article.

Dedicated QA teams should be avoided unless truly necessary. Otherwise, you have the same problem of developers throwing over under-tested code to a group of separate people that are smart but treated poorly.

A QA guy who loves to write automation gets the same promises... "oh you'll be programming mostly; manually test maybe once a month". But when they get into the door, it's the exact opposite.

Developers should all be passionate about QA (read as: the quality of their product), as well as how their product is actually deployed (read as: executed in the most important of environments--production!).

I work at JamKazam--

This is running the Linux real time kernel to help us achieve extremely low latency and I/O jitter. We've had to do a ton of fine tuning to get the latency as low as it is.

Our website is built on Ruby-on-Rails backed by Postgresql. We are using Resque for asynchronous jobs, and a Websocket/RabbitMQ solution to help with events in the browser and events else where in the backend.

Our JavaScript is a homegrown mess (jQuery and, ahem, 'business logic'). Having kept up with the latest web tech mostly through HN, I'd take the React/Flux plunge if starting from scratch; I'm still looking for an excuse to start using them anyway, even if just for part of the site!

Anyway, we are very excited to be starting the KickStarter for the JamBlaster, because it's your best way to get the latency low enough to have a really good jam session.

/me fingers crossed

I have completely 180'ed on this topic. I used to think to be a successful startup, you all had to be in the same room, ideally at a big huge desk etc.

After working at my current startup, I realize I was wrong. We are an entirely remote operation, and have been since day 1. A few of us are in Austin, and rarely meet for a face-to-face, but it's more of a 'oh yeah, you actually exist' meeting rather than a hash-it-out sort of meeting.

I think the reason we have been successful is because being remote has forced us to write things down, in our wiki (in the form of product specs) and in JIRA (in the form of specific features and bug fixes). With just those two forms of written communication, we've solved 95% of our communication needs. We almost never skype or use video conferencing... it's just not needed.

The other reason we are successful is due to experience. We've all done startups before, so we know the drill. I can't emphasis how important this is enough, but does deserve more explanation. (unfortunately I can't muster the amount of typing atm).

IN the end, we can focus on getting work done... without the distraction of office chatter, commuting, long lunches.