Indeed, however, my
Indeed, however, my
Word would auto-create them. The user would then copy-paste from word into their fav HTML editor. The resultant character codes would then appear as upside-down question-marks on every other browser except IE.
Then fixing them for Firefox caused them to not work in IE.
The "internet" didn't do it: the browser-wars did.
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.
The next person to mention spaghetti stacks to me is going to have his head knocked off. -- Bill Conrad