Internets cross state lines, and so there is Federal jurisdiction. Only the state in which the crime is committed (which can be ambiguous here) would have an interest, and state law in this case would typically be less specific.
You're implying that the author meant to make the crime seem more serious by their use of "Federal". I don't make that assumption. They just accurately stated the likely jurisdiction and who would likely investigate and prosecute.
The Hycopter uses its frame to store energy in the form of hydrogen instead of air.
FTW?
What drones are powered by air? Most are powered by electricity or hydrocarbon fuel.
I suppose one *could* be powered by compressed air. I know of none. (Yea, I'm sure somebody will find one, though, and link it here. They aren't common though.)
Horribly-written article. Suspect "Steve Crowe" ("author") is a bot. Link-bait.
Subject says it.
I kept all those AOL CDs for just this purpose. For many years. It was quite a pile! Then decided that was silly when I moved. Gone, years, ago.
If you find them in Asian landfills, it will answer a burning controversy. Is that where this stuff goes? Or not?
But I do have some stuff. Just not as common as AOL CDs.
Hmmm...
- Wired Rip. Sample. Mash. Share. Some rights reserved.
Ohh, ohh, ohh, HotMetal Pro 6.0
Buncha CDs that came in the back of expensive paperback tech books from Bookstar. Microsoft developer-type stuff, ATL, COM, etc.
The usual collection of drivers and install disks for long-dead hardware and long-obsolete software, that everybody else has too.
AOLs and shareware CDs gone, baby, gone!
Well, you're not getting this (in part because it's proprietary source code) but I just found a 1985 floppy with source code for what is now Siemens TeamCenter Lifecycle Visualization Variation Analysis. (OK, half the source code, cause it says disk 1 of 2, and I don't have 2. Or a 5" floppy drive.) 30 year old software that is still alive and kicking, and has been (and is) instrumental in the design of... well, probably everything that anybody here drives, flies in, blows somebody up with, or records data on (if it rotates...). I guess NDAs are still good 30 years later, huh?:( Wonder if Siemens might like it? This is version 1.0.3. It's in my old "code samples box".
I guess if you were into how and why mass-produced mechanical thingies that fit together have been made to fit-together so much better and better over the past 30 years, that one might represent some significant bit of geeky history.
It's a pattern detection strategy that relies on generating waves with input data, interweaving them physically, and using arrays of antennas to detect patterns.
So, mature, third-party, solid, stable, best-in-class, tried-and-true libraries that are the standard foolproof way to do "X" (choose from many "X"s) will all re-write themselves from C or C++ to Swift, and then keep themselves in sync with the mainline library, right?
C and C++ will continue to be used in iOS apps for the same reasons that so many (of the better...) Android apps color outside of the approved Java lines and use C/C++ using the NDK.
Many/most policies have several occurrences which will VOID the insurance. That means that the driver doesn't have any personal insurance, and in most states then will be in violation of state law.
These occurrences will usually include:
- lying on the insurance application
Most/all applications ask if the vehicle will be used commercially.
In fact, there have now been several occurrences now where driver's insurance refused to pay, Uber insurance did indeed pay, but driver's insurance company voided their insurance, and now no insurance company will write insurance for that driver.
Uber will cover the passenger. (But, according to a local "TV troubleshooter" investigation, not eagerly or quickly...). Uber will cover the driver's liability for the incident. But driver may no longer be able to drive. At all.
So many comments here miss the mark so widely. There is NO implication that a hybrid (or, more broadly cross-platform) native app has to rely on a server. None, zero, zip, zilch, nada. None.
You DO NOT NEED a server for native hybrid app! Only if you happen to need a centralized database. Use a server if you need a server. Period. For example, you have an app that shows current news, current sales figures, that updates the company database in some way? You are going to have one or more servers involved.
If you need a server, you need a server, whether webapp, hybrid app, or fully-native app. If you don't need a server, you don't need a server.
Even a "webapp" doesn't need a server, once the webapp is loaded onto the device.
Local databases are a common feature of hybrid apps, especially in the Enterprise world. Sync the local database to a central database when connectivity is present. Users can continue to work with the app offline. Of course, this is no different than with a native app. The argument is fallacious - you are imagining an architectural model that simply isn't common. Hybrid apps do not have any different networking requirements than native apps. That is, if they need access to a network, then they need access to a network. Nothing about the architecture demands servers.
The article isn't talking about webapps, nor is it talking about apps that require a server. It's focused on hybrid native-app platforms that leverage the use of a WebView for UI. The pages that the WebView displays don't have to come from a server over a network.
Facebook gave up too early. On the other hand, Facebook can afford the development cost of native. For many other applications, native is unaffordable, especially for multiple platforms.
(Thank you, though, Facebook, for (before giving up on hybrid) figuring-out how to shut off the *&^%$#! iOS WebView "accessory view", and using your Facebook-powers to cow Apple into looking the other way when apps go digging into the virtual keyboard windows to shut that evil thing off...)
Embedded WebViews have gotten much better. Android has been the laggard, with awful animation/transition performance and glitchiness prior to 4.x, and user reluctance to upgrade OS (improved now) and inability to upgrade on many devices (alas, not much improved, so many Android devices cannot be upgraded to latest OS.)
Certainly, on iOS at least, I think most users would be hard-pressed to tell the difference between well-written hybrid apps and native.
I use (Zebra, was Motorola, and before that RhoMobile) Rhodes. I've also developed using PhoneGap/Cordova. I would not do a large project in PhoneGap/Cordova, because everything has to be done in Javascript. With Rhodes, I write models and controllers in Ruby, views in ERB (wish it had a better template language...) and code that touches the UI directly in Javascript. It's a very comfortable platform if you have been a Rails developer, because it's very similar - the server has been placed in the application.
I'd say at least half my development time is spent with JS and CSS (actually, I use SCSS). I see that as a good thing. I can tweak the UI interactively by twiddling CSS in Safari or Chrome desktop (developer tools for both can connect remotely to a device for inspection/debug/experiment.) I can easily teach a designer to do that themselves. Contrast that to the painful process of tweaking a native UI, being forced to use platform-unique tools and go through a slow and painful build process to see the smallest result.
I've been working with a small team implementing a number of similar energy-conservation apps (they are used by professional energy auditors - organizations are opinionated, that's why there are 6 apps...). I really think the effort would have been insurmountable had it been done with native code. This is not a typical consumer app with a few screens, but ones with dozens of pages of data-collection forms (per audited building). It's not your typical consumer app with some kind of silly one-page dashboard with text in circles...
If I had to do something with charts/graphs, I certainly would leverage the great JS libraries that are available, rather than struggling with native code! We did do a little sketch tool in JS (sketch over photos for annotation - just browser API) and nobody would ever know it is not native.
Ultimately, we abandoned Android (at least for now) due to poor performance and Balkanization, but I can see Android being supported in the future again.
I have not used Xamarin. It seems the worst of all worlds to me. You have to use the native API of each platform, but you write in a common language (C# yuck!). Where is the saving in development time here?
I strongly disagree with the bit about "different screen sizes" etc. being problematical. Using HTML helps solve that problem. It's easy to create flexible layouts using responsive CSS. Yes, native platforms have gotten better about this. But it's impossible to get designers directly involved, using the tools that they are familiar with. They still have to toss wire-frames "over the cubical wall" and the battle it out with programmers as to whether their fantasy UIs are even possible. With HTML5, they can work with what they are familiar with and provide complete solutions for UI bits. As well, there is an amazing volume of free and really quite high-quality resources for CSS3 effects, etc. that can be leveraged.
Yea, if you have a million-dollar budget for a small app, go for native. The rest o
When you receive a call you'll usually see the number of the caller, but this may not be helpful in identifying them before you decide whether to pick up.
here, but not in the usual sense of that phrase, but in the way it would be used in Newspeak.
A musical "remix" is almost always longer than the original. As in "extended remix". Almost all musical remixes are "extended remixes", and so we associate the term with expansion, not contraction - with more, not less.
If you have only a short time to see a number of different places, and you are an a**hole, yes, please use a Segway or hail one of those obnoxious pedicabs (in case you have brought your whole a**hole family...)
If you are a "Segway train" group leader, make sure to call out to pedestrians "watch out to your left, passing by" while barely missing them, instead of riding in a more appropriate place.
Now, it's such a nice day, I think I'll go walk down to the Embarcadero (San Diego). The cruise ships are in! I can take my choice of doom - Segway, Pedicab, kidnapped by Falun Gong (probably not, I don't look like a Chinese party-member tourist), or norovirus.
The TLD should never have been approved in the first place. It simply invites abuse. This should have been obvious. What kind of idiots decided this?
A company/brand simply cannot win on this. If the company caves-in and buys the domain, now they are in a position of owning a domain that says that their company/brand sucks. What do they do then? Put up a page saying "not really"?
How can you prove that they are fake? Because the site says so in it's opening paragraph:
Are you tired of your products not being seen, tired of competitors leaving bad reviews? The solution is simple. Buy Amazon reviews. You can have unlimited 4 and 5 star reviews this week. Our skilled writers look at your product, look at your competitor’s products and then write state of the art reviews that will be sure to generate sales for you.
BTW, requiring verified purchase does not solve the problem. That site will buy the product if it is $2 or less. You can have "verified purchase" on higher-priced products by "making arrangements". I assume they then ship the product back to the manufacturer, so they only lose shipping and Amazon's profit. LOL, I'll bet they have Amazon ship it right to the manufacturer! (Or to an employee.)
As well, developers go to StackOverflow because they have problems. So, the survey shows us the popularity of technologies that are poorly-documented and/or difficult to understand.
GenyMotion (Android simulator) has this built-in, as does the iOS simulator.
This could be done on an open-source router, as well, instead of using a computer behind the router.
And, ironically - doesn't Facebook have some powerful Cisco routers that probably have this sort of thing built-in (or optional?)
Apple Watch's "chief feature" is neither time-keeping nor fitness-tracking.
It's chief feature is a connected touchscreen on your wrist. Period.
Those so-called "chief features" are just necessary features because we only have enough room for one device on each wrist, only have two wrists, and people would feel silly wearing a device on each wrist.
A watch functionality and a fitness-tracker functionality are just needed because otherwise many people would have an excuse to wear something else on their wrist instead of an Apple connected touchscreen.
Register a domain with a domain registration company (duh!)
You should host your DNS elsewhere. Use a DNS-hosting company.
Host your website(s) elsewhere. Use a web-hosting company.
Host your email elsewhere. Use an email service provider.
This gives you maximum flexibility, and means that no one company can "hold you hostage".
It's ridiculous the mention names. People just vote for their favorite consumer-ish registration or hosting company. If you care about names, though - the ones that are mentioned are generally the ones to avoid...
Slashdot Mirror
Oh, lord! Guess they'll be snap-chatting my feeding tube to their friends, too!
Internets cross state lines, and so there is Federal jurisdiction. Only the state in which the crime is committed (which can be ambiguous here) would have an interest, and state law in this case would typically be less specific.
You're implying that the author meant to make the crime seem more serious by their use of "Federal". I don't make that assumption. They just accurately stated the likely jurisdiction and who would likely investigate and prosecute.
Who openly posts solicitations to commit a Federal crime, while positively identifying themselves through social media?
The same people that Liberty Mutual doesn't want going around driving three-quarters of a car, that's who!
What will those clueless Millennials do next?
FTW?
What drones are powered by air? Most are powered by electricity or hydrocarbon fuel.
I suppose one *could* be powered by compressed air. I know of none. (Yea, I'm sure somebody will find one, though, and link it here. They aren't common though.)
Horribly-written article. Suspect "Steve Crowe" ("author") is a bot. Link-bait.
Currently, Sublime Text.
- Wired Rip. Sample. Mash. Share. Some rights reserved.
Ohh, ohh, ohh, HotMetal Pro 6.0
Buncha CDs that came in the back of expensive paperback tech books from Bookstar. Microsoft developer-type stuff, ATL, COM, etc.
The usual collection of drivers and install disks for long-dead hardware and long-obsolete software, that everybody else has too.
AOLs and shareware CDs gone, baby, gone!
Well, you're not getting this (in part because it's proprietary source code) but I just found a 1985 floppy with source code for what is now Siemens TeamCenter Lifecycle Visualization Variation Analysis. (OK, half the source code, cause it says disk 1 of 2, and I don't have 2. Or a 5" floppy drive.) 30 year old software that is still alive and kicking, and has been (and is) instrumental in the design of... well, probably everything that anybody here drives, flies in, blows somebody up with, or records data on (if it rotates...). I guess NDAs are still good 30 years later, huh? :( Wonder if Siemens might like it? This is version 1.0.3. It's in my old "code samples box".
I guess if you were into how and why mass-produced mechanical thingies that fit together have been made to fit-together so much better and better over the past 30 years, that one might represent some significant bit of geeky history.
So, it's an analog computer.
So, mature, third-party, solid, stable, best-in-class, tried-and-true libraries that are the standard foolproof way to do "X" (choose from many "X"s) will all re-write themselves from C or C++ to Swift, and then keep themselves in sync with the mainline library, right?
C and C++ will continue to be used in iOS apps for the same reasons that so many (of the better...) Android apps color outside of the approved Java lines and use C/C++ using the NDK.
Many/most policies have several occurrences which will VOID the insurance. That means that the driver doesn't have any personal insurance, and in most states then will be in violation of state law.
These occurrences will usually include:
- lying on the insurance application
Most/all applications ask if the vehicle will be used commercially.
In fact, there have now been several occurrences now where driver's insurance refused to pay, Uber insurance did indeed pay, but driver's insurance company voided their insurance, and now no insurance company will write insurance for that driver.
Uber will cover the passenger. (But, according to a local "TV troubleshooter" investigation, not eagerly or quickly...). Uber will cover the driver's liability for the incident. But driver may no longer be able to drive. At all.
So many comments here miss the mark so widely. There is NO implication that a hybrid (or, more broadly cross-platform) native app has to rely on a server. None, zero, zip, zilch, nada. None.
You DO NOT NEED a server for native hybrid app! Only if you happen to need a centralized database. Use a server if you need a server. Period. For example, you have an app that shows current news, current sales figures, that updates the company database in some way? You are going to have one or more servers involved.
If you need a server, you need a server, whether webapp, hybrid app, or fully-native app. If you don't need a server, you don't need a server.
Even a "webapp" doesn't need a server, once the webapp is loaded onto the device.
Local databases are a common feature of hybrid apps, especially in the Enterprise world. Sync the local database to a central database when connectivity is present. Users can continue to work with the app offline. Of course, this is no different than with a native app. The argument is fallacious - you are imagining an architectural model that simply isn't common. Hybrid apps do not have any different networking requirements than native apps. That is, if they need access to a network, then they need access to a network. Nothing about the architecture demands servers.
The article isn't talking about webapps, nor is it talking about apps that require a server. It's focused on hybrid native-app platforms that leverage the use of a WebView for UI. The pages that the WebView displays don't have to come from a server over a network.
Facebook gave up too early. On the other hand, Facebook can afford the development cost of native. For many other applications, native is unaffordable, especially for multiple platforms.
(Thank you, though, Facebook, for (before giving up on hybrid) figuring-out how to shut off the *&^%$#! iOS WebView "accessory view", and using your Facebook-powers to cow Apple into looking the other way when apps go digging into the virtual keyboard windows to shut that evil thing off...)
Embedded WebViews have gotten much better. Android has been the laggard, with awful animation/transition performance and glitchiness prior to 4.x, and user reluctance to upgrade OS (improved now) and inability to upgrade on many devices (alas, not much improved, so many Android devices cannot be upgraded to latest OS.)
Certainly, on iOS at least, I think most users would be hard-pressed to tell the difference between well-written hybrid apps and native.
I use (Zebra, was Motorola, and before that RhoMobile) Rhodes. I've also developed using PhoneGap/Cordova. I would not do a large project in PhoneGap/Cordova, because everything has to be done in Javascript. With Rhodes, I write models and controllers in Ruby, views in ERB (wish it had a better template language...) and code that touches the UI directly in Javascript. It's a very comfortable platform if you have been a Rails developer, because it's very similar - the server has been placed in the application.
I'd say at least half my development time is spent with JS and CSS (actually, I use SCSS). I see that as a good thing. I can tweak the UI interactively by twiddling CSS in Safari or Chrome desktop (developer tools for both can connect remotely to a device for inspection/debug/experiment.) I can easily teach a designer to do that themselves. Contrast that to the painful process of tweaking a native UI, being forced to use platform-unique tools and go through a slow and painful build process to see the smallest result.
I've been working with a small team implementing a number of similar energy-conservation apps (they are used by professional energy auditors - organizations are opinionated, that's why there are 6 apps...). I really think the effort would have been insurmountable had it been done with native code. This is not a typical consumer app with a few screens, but ones with dozens of pages of data-collection forms (per audited building). It's not your typical consumer app with some kind of silly one-page dashboard with text in circles...
If I had to do something with charts/graphs, I certainly would leverage the great JS libraries that are available, rather than struggling with native code! We did do a little sketch tool in JS (sketch over photos for annotation - just browser API) and nobody would ever know it is not native.
Ultimately, we abandoned Android (at least for now) due to poor performance and Balkanization, but I can see Android being supported in the future again.
I have not used Xamarin. It seems the worst of all worlds to me. You have to use the native API of each platform, but you write in a common language (C# yuck!). Where is the saving in development time here?
I strongly disagree with the bit about "different screen sizes" etc. being problematical. Using HTML helps solve that problem. It's easy to create flexible layouts using responsive CSS. Yes, native platforms have gotten better about this. But it's impossible to get designers directly involved, using the tools that they are familiar with. They still have to toss wire-frames "over the cubical wall" and the battle it out with programmers as to whether their fantasy UIs are even possible. With HTML5, they can work with what they are familiar with and provide complete solutions for UI bits. As well, there is an amazing volume of free and really quite high-quality resources for CSS3 effects, etc. that can be leveraged.
Yea, if you have a million-dollar budget for a small app, go for native. The rest o
What kind of obsolete phone have you been using?
There is an implied:
here, but not in the usual sense of that phrase, but in the way it would be used in Newspeak.
A musical "remix" is almost always longer than the original. As in "extended remix". Almost all musical remixes are "extended remixes", and so we associate the term with expansion, not contraction - with more, not less.
Some very clever Newspeak, Ms. Mayer!
It doesn't take ANY margin to place an order - only if the order is executed!
As well, professional traders work with different (much more liberal) margin rules.
If you have only a short time to see a number of different places, and you are an a**hole, yes, please use a Segway or hail one of those obnoxious pedicabs (in case you have brought your whole a**hole family...)
If you are a "Segway train" group leader, make sure to call out to pedestrians "watch out to your left, passing by" while barely missing them, instead of riding in a more appropriate place.
Now, it's such a nice day, I think I'll go walk down to the Embarcadero (San Diego). The cruise ships are in! I can take my choice of doom - Segway, Pedicab, kidnapped by Falun Gong (probably not, I don't look like a Chinese party-member tourist), or norovirus.
The TLD should never have been approved in the first place. It simply invites abuse. This should have been obvious. What kind of idiots decided this?
A company/brand simply cannot win on this. If the company caves-in and buys the domain, now they are in a position of owning a domain that says that their company/brand sucks. What do they do then? Put up a page saying "not really"?
How can you prove that they are fake? Because the site says so in it's opening paragraph:
BTW, requiring verified purchase does not solve the problem. That site will buy the product if it is $2 or less. You can have "verified purchase" on higher-priced products by "making arrangements". I assume they then ship the product back to the manufacturer, so they only lose shipping and Amazon's profit. LOL, I'll bet they have Amazon ship it right to the manufacturer! (Or to an employee.)
As well, developers go to StackOverflow because they have problems. So, the survey shows us the popularity of technologies that are poorly-documented and/or difficult to understand.
Both the best and the worst developers are unlikely to have every used StackOverflow...
See subject.
GenyMotion (Android simulator) has this built-in, as does the iOS simulator. This could be done on an open-source router, as well, instead of using a computer behind the router. And, ironically - doesn't Facebook have some powerful Cisco routers that probably have this sort of thing built-in (or optional?)
Apple Watch's "chief feature" is neither time-keeping nor fitness-tracking.
It's chief feature is a connected touchscreen on your wrist. Period.
Those so-called "chief features" are just necessary features because we only have enough room for one device on each wrist, only have two wrists, and people would feel silly wearing a device on each wrist.
A watch functionality and a fitness-tracker functionality are just needed because otherwise many people would have an excuse to wear something else on their wrist instead of an Apple connected touchscreen.
Do NOT register a domain with:
Register a domain with a domain registration company (duh!)
You should host your DNS elsewhere. Use a DNS-hosting company.
Host your website(s) elsewhere. Use a web-hosting company.
Host your email elsewhere. Use an email service provider.
This gives you maximum flexibility, and means that no one company can "hold you hostage".
It's ridiculous the mention names. People just vote for their favorite consumer-ish registration or hosting company. If you care about names, though - the ones that are mentioned are generally the ones to avoid...
... every which way to Sunday.