The cops can stop you, see you have lots of cash, accuse the cash itself (not you, just the cash) of being involved in or related to a crime, seize the cash, and later use it to buy themselves more military hardware from the government in order to be able to repeat the cycle on even more innocent drivers.
This happens along I-40 and other routes to Vegas all the time, as professional poker players and other gamblers who play in cash-only games and thus need to be traveling with 10 to 20 thousand at a time will attest to often.
I can't stand Ruby and gems because updates to things are so fragile. We're dependent on a lot of libraries (through dependencies of dependencies) and if any one of them is not THE version it is supposed to be, everything breaks. Fortunately this is just our build tools (the app is using an older version of SproutCore). If it was deployment on production, we'd be totally screwed because we'd never be able to upgrade anything and would be vulnerable to security issues constantly.
NPM/node runs that same risk (the second i saw there was an "nvm" available, I knew things were going downhill), but the idea of dockers is a better way to protect one application and its version dependencies from another.
They don't even need to ask. All they need to do is somehow link up your phone and account with your Google, Facebook, and Amazon cookies and they can get all of that info they want.
Indeed. or pre-writing the 'trilogy' to fit the star wars original trilogy pattern, the Campbell Story (episode one) embedded within the larger Campbell Story (the whole trilogy), then...throw it all away and reboot so you can do it again to a new generation. Sam Raimi's Spiderman set certainly fits this bill, but there are others.
Trouble is, as soon as you step away from the stereotypes and tropes and get 'original'...something falls short and then everybody's hunting around for what caused it to jump the shark (not that anybody uses that phrase anymore). There's actually some really good ideas tucked inside Pirates 2, 3, and 4...but because it doesn't directly fit a pattern we know, they're harder to grasp...so instead we're grasping for why the films aren't as good as that first one.
Hollywood is in a bind there - the *discerning* audience wants something different and new and not retreads...but the discerning audience doesn't pay as much (and is MUCH more vocally critical when things still aren't right even if they can't explain why).
So they decide to tell us, the discerning audience, to f' off, and they'll take the money instead from the rest of the rubes.
On the bright side, sci-fantasy genre TV has gotten a lot better in the last few years.
"The funniest scene in the trailer isn't in the movie."
This was so true with the Bill Murray / Richard Dreyfuss "What About Bob?" - the high point of the trailer was, clearly after the house blew up, Bill Murray yelling (but totally deadpan about it) "OH MY GOD your house.". We waited the entire film for that line when the explosion happened and...nothing. Totally cut. Never existed.
It was actually more annoying and depressing than not having somebody face down a tie fighter on a balcony. more than 25 years later it STILL bugs me.
Because this is *exactly* the situation that will result in the revolution where-upon several advertising and marketing executives will be the first against the wall.
Mind you, I hated how their app framework required you to use alternatives to HTML5 standards. You had no browser history/routing (had to fake/polyfill that), and no standard localStorage (have to use proprietary callback based API), and even image loading from http CORS sources is f'ed.
So yeah, Chrome App development was painfully annoying...but they could have resolved that without just dropping the whole engine.
The parallels to Chrome's handling of this and the GOP's handling of the Obamacare replacement are rather impressive.
But then they decided to get rid of their Apps framework and only support extensions (unless you're on Chromebook...and that may go away too if they ever get Android Apps on Chromebook working right).
Now it is just a browser with some annoying security restrictions and a need for a ton of extensions. It isn't an app engine platform in the way it used to be, at least not until they figure out how to support PWAs on desktop.
Firefox is supporting the common extensions framework (though not very well) and PWAs on Android (though not very well - they don't support standalone/fullscreen yet, which is ridiculous), so Chrome's losing some of what made it a platform to target.
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.
"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."
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.
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.
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.
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.
But if I just leave the API key in the app's scripts, it can, with a little bit of research in the web console, be found by anybody looking for it. Even if I were to encrypt it in some way, that encryption could be cracked easily because everything needed to decode it could also be found because it all is in the javascript somewhere.
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.
Slashdot Mirror
So yeah, just like all the answers above, if thieves know you have a lot of cash, they will rob you.
it just happens that some of the thieves carry badges.
The cops can stop you, see you have lots of cash, accuse the cash itself (not you, just the cash) of being involved in or related to a crime, seize the cash, and later use it to buy themselves more military hardware from the government in order to be able to repeat the cycle on even more innocent drivers.
This happens along I-40 and other routes to Vegas all the time, as professional poker players and other gamblers who play in cash-only games and thus need to be traveling with 10 to 20 thousand at a time will attest to often.
I can't stand Ruby and gems because updates to things are so fragile. We're dependent on a lot of libraries (through dependencies of dependencies) and if any one of them is not THE version it is supposed to be, everything breaks. Fortunately this is just our build tools (the app is using an older version of SproutCore). If it was deployment on production, we'd be totally screwed because we'd never be able to upgrade anything and would be vulnerable to security issues constantly.
NPM/node runs that same risk (the second i saw there was an "nvm" available, I knew things were going downhill), but the idea of dockers is a better way to protect one application and its version dependencies from another.
They don't even need to ask. All they need to do is somehow link up your phone and account with your Google, Facebook, and Amazon cookies and they can get all of that info they want.
Indeed. or pre-writing the 'trilogy' to fit the star wars original trilogy pattern, the Campbell Story (episode one) embedded within the larger Campbell Story (the whole trilogy), then...throw it all away and reboot so you can do it again to a new generation. Sam Raimi's Spiderman set certainly fits this bill, but there are others.
Trouble is, as soon as you step away from the stereotypes and tropes and get 'original'...something falls short and then everybody's hunting around for what caused it to jump the shark (not that anybody uses that phrase anymore). There's actually some really good ideas tucked inside Pirates 2, 3, and 4...but because it doesn't directly fit a pattern we know, they're harder to grasp...so instead we're grasping for why the films aren't as good as that first one.
Hollywood is in a bind there - the *discerning* audience wants something different and new and not retreads...but the discerning audience doesn't pay as much (and is MUCH more vocally critical when things still aren't right even if they can't explain why).
So they decide to tell us, the discerning audience, to f' off, and they'll take the money instead from the rest of the rubes.
On the bright side, sci-fantasy genre TV has gotten a lot better in the last few years.
"The funniest scene in the trailer isn't in the movie."
This was so true with the Bill Murray / Richard Dreyfuss "What About Bob?" - the high point of the trailer was, clearly after the house blew up, Bill Murray yelling (but totally deadpan about it) "OH MY GOD your house.". We waited the entire film for that line when the explosion happened and...nothing. Totally cut. Never existed.
It was actually more annoying and depressing than not having somebody face down a tie fighter on a balcony. more than 25 years later it STILL bugs me.
Because this is *exactly* the situation that will result in the revolution where-upon several advertising and marketing executives will be the first against the wall.
At first I figured it had to be, since as far as I can tell, this is the first of Obama's executive orders that Trump or Congress HAVEN'T rescinded.
Mind you, I hated how their app framework required you to use alternatives to HTML5 standards. You had no browser history/routing (had to fake/polyfill that), and no standard localStorage (have to use proprietary callback based API), and even image loading from http CORS sources is f'ed.
So yeah, Chrome App development was painfully annoying...but they could have resolved that without just dropping the whole engine.
The parallels to Chrome's handling of this and the GOP's handling of the Obamacare replacement are rather impressive.
But then they decided to get rid of their Apps framework and only support extensions (unless you're on Chromebook...and that may go away too if they ever get Android Apps on Chromebook working right).
Now it is just a browser with some annoying security restrictions and a need for a ton of extensions. It isn't an app engine platform in the way it used to be, at least not until they figure out how to support PWAs on desktop.
Firefox is supporting the common extensions framework (though not very well) and PWAs on Android (though not very well - they don't support standalone/fullscreen yet, which is ridiculous), so Chrome's losing some of what made it a platform to target.
Indeed, however, my .sig quote seems surprisingly relevant...
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."
https://en.wikipedia.org/wiki/...
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.
answering my own, bookmarking to read later:
http://billpatrianakos.me/blog...
which was a follow-up to
http://billpatrianakos.me/blog...
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.
But if I just leave the API key in the app's scripts, it can, with a little bit of research in the web console, be found by anybody looking for it. Even if I were to encrypt it in some way, that encryption could be cracked easily because everything needed to decode it could also be found because it all is in the javascript somewhere.
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.