Darn it! Beat me to it!

Or OP has a stutter...

I think the only way you can make that kind of money is networking is dodging bullets - either literal or figurative.

Either you are going to have a high-stress job where you will be on-call 24/7 and people will be yelling at you all day, or you need to go to Irag, Afghanistan, etc. etc. etc.

Just find a job outside of the Bay Area. You will take a pay cut, but you will come out ahead.

I hope you haven't been counting on those stock options that, in the vast majority of cases, will ultimately be worth --- nothing. (statistically, if you work for a venture-funded startup.)

You beat me to it. FAT wires. Just sayin'. It'll work just fine, so long as you live in a castle, and have one hell of a drill bit to install the wires in the wall.

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?

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.

Currently, Sublime Text.

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, 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 of us are well-served today by hybrid. Most of these are apps that the public will never see. BTW, speaking of Home Depot - those devices they carry - they're Motorola (now Zebra) devices. And they've developed internal apps for them using Rhodes. Along with McDonald's, Hormel, many others with similar needs. Just can't imagine developing these types of enterprise apps using native code exclusively! Even with dedicated devices, BYO is very important to these companies, for management, off-site, etc. Nobody wants to be tethered to an extra company-supplied device when they go home! The device on their belt might have a built-in printer or scanner, and need some specific support for that on a specific platform, but basic functionality still needs to be available on consumer devices.