raise your ISO.
raise your ISO.
"The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor."
it has impacts in a great many areas, including the test-based teacher and school evaluations.
The API to actually detect whether or not chromecast is available changed in the switch from extension to built-in.
Quite a few software systems, particularly packages with few dedicated developers including Subsonic, are now broken.
Actually, that's a very good point. It also means that as developers, the only way we can test our apps now is to purchase a chromebook to test on. I can't just test it on my Mac and go "this works" and push it up knowing it'll just work on the chromebook.
Now I would have to build on the mac, send the package over to the chromebook (which I now have to have) and test it there, and repeat ad nauseum for bug fixes, before I can finally push it up.
Chrome app development worked because any normal dev platform could also be your test box. Soon? not so much.
there. fixed it for you.
Seriously, this is insulting. You work through college, you get a professional degree. You should be getting a job with real benefits, not a job that requires you to pay a quarter of your salary to the ACA, no 401K, etc.
Part time work is not a panacea. It is a step backwards, a trend that will treat professional developers with the same respect as a walmart greeter, if not checked.
We as developers deserve better.
you'd have to look up the details (there's an extension to do that), but one "clue" is whether or not there is a forced nav bar from the window manager on the window. My own app was originally hosted, but at some point Chrome forced it to have the O/S's native drag-bar, which I didn't want. Packaging as a deployed app, as opposed to a hosted one, solved that. It required making other changes to the code around local storage and browser history (two items that Chrome deployed apps disabled, for reasons I still don't respect), but I did it, because the aesthetic quality of having my music player with no "chrome" from the O/S was important to me.
So I'm rather pissed off at Chrome right now for this.
Yeah, but Android Apps on Chrome on the O/S is a hell of a lot of overhead for a basic HTML5 single-page that you would just rather package and have in an independent window rather than forcing the user to always have to keep a tab open.
I have a Chrome app music player (a client for subsonic), an html5 app that I also serve on the web and deploy on Amazon's Fire OS platform. For a time it was on Firefox as well as an app but they eliminated their "app" capability a year ago.
The problem is that I want this music player to be independent, as most music players are. I don't want to force the user to keep it in a tab, stuck in size to the window of the rest of the browser. I *like* having them be able to open it independently, size it to what they want, etc, just as they would the player if it was native.
Now, with Chrome throwing this away, I am going to have to look at new deployment tech like electron, which adds a huge amount of overhead (though less than running in an Android interpreter) for the same feature set that Chrome was giving me effectively for free.
With 50 and 51, one could preview the new media by turning on a chrome://flags setting. That setting is now default 'on' instead of off with 52. With html5 audio tag, it fixes a lot of streaming issues with constant bit-rate files (duration wouldn't update, and you'd not get an 'end' event when the song finished, things that worked fine for variable bitrate files), issues that were also in the webview as well. So those web apps that need html5 audio tag will work much better, and phonegap/cordova apps will when the webview for Android goes out, hopefully soon after the browser...
Indeed, if your goal is audio fidelity, you wouldn't be finding it in mp3 or aac files (or streaming sources like spotify or apple radio) in the first place.
This seems to be what JWT and other token-based auth systems are moving to, as I've kept reading up on things this morning. Thanks.
Any time you keep credentials on a public hub is just a bad thing to do (in a "cross the streams" sense), and I addressed that in a blog entry back when bots were finding thousands of Amazon AWS and S3 OAuth credentials and secret keys made public on github.
But I do wonder, for libraries that give you an API token to use (Flickr, Trello), how should one use it in a pure html5 single-page client app, one that doesn't use any server proxy middleware. E.g., except for securing the API key, there's no reason for a flickr photo slideshow to ever need to talk to my own server: it should just talk to Flickr directly. Routing everything through my server as a proxy just for the API key would be horribly inefficient and expensive on my bandwidth, as well as unnecessarily slow.
So what if any is the solution for efficient CORS-based HTML5 single page apps for APIs that require a key that you should attempt to secure in some way to prevent others from using the key to create abusive applications of their own?
see my other post - in addition to being more demanding, many (esp HBO and Disney) are looking to build or already have their own competing service, and the value of that service depends on having exclusives.
It really has nothing to do with international rights. Cost may be a factor, but it isn't the most important right now. They can license whatever the studios will sell them.
The studios aren't selling.
The reason is that they figure they've got the killer show that is enough to get them to install the service for just that studio's output. HBO and Starz are already exclusives (with HBO recently revoking Netflix's license with Sesame Street), Disney's working on theirs, CBS has forked off their own instead of signing on to Hulu with the other networks.
At $15/m, they figure they've got the one killer show that is enough to get that monthly subscription, and they're gambling they're right by taking their material off of Netflix.
In the end, "cutting the chord" is not going to save anybody any money, because instead of paying cable $99+ / month for shows and HBO, they're going to have to sign on to 7 services to get the same shows they want to watch, resulting in the same $99/month.
well, to get us to use the cloud for that, they would need to have their cloud-editing tools not suck.
They bought picnik and totally ran it into the dirt, where all that is left is a handful of astronomy-named one-shot filters that make me miss instagram, and i've never actually installed instagram for f's sake.
Otherwise, you can do more editing on your phone/tablet than you can on your desktop, and that is one gigantic bit of what-the-f round two. The idea that mobile should be *better* than desktop is an attitude I will simply never ever understand.
Disclaimer: "These opinions are my own, though for a small fee they be yours too." -- Dave Haynie