Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment: Re:"federal" crimes? (Score 1) 75

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.

Comment: Who does this? A. Millennials! (Score 2) 75

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?

Comment: "instead of air"? FTW? (Score 1) 116

by jtara (#49743903) Attached to: Hydrogen-Powered Drone Can Fly For 4 Hours at a Time

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.

Comment: Be careful what you wish for! (Score 2, Interesting) 123

by jtara (#49733279) Attached to: Jason Scott of Textfiles.com Wants Your AOL & Shovelware CDs
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.

Comment: Mature, third-party libraries... (Score 1) 270

by jtara (#49670511) Attached to: Swift Vs. Objective-C: Why the Future Favors Swift

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.

Comment: Re: Uber cars not covered by insurance (Score 1) 302

by jtara (#49630525) Attached to: Uber Forced Out of Kansas

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.

Comment: Re: No (Score 1) 161

by jtara (#49565825) Attached to: Has the Native Vs. HTML5 Mobile Debate Changed?

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.

Comment: Yes - Facebook quit too soon (Score 2) 161

by jtara (#49562769) Attached to: Has the Native Vs. HTML5 Mobile Debate Changed?

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.

Comment: It's NewSpeak (Score 0) 194

by jtara (#49531531) Attached to: Yahoo Called Its Layoffs a "Remix." Don't Do That.
  • War is Peace
  • Freedom is Slavery
  • Ignorance is Strength

There is an implied:

Less is More

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!

Logic doesn't apply to the real world. -- Marvin Minsky

Working...