I think they could make threads work with some simple changes:
* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.
* Allow the user to collapse a thread so they no longer see it in-line.
* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).
* Allow the user to navigate between threads using only their keyboard.
As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).
I'm also surprised at the amount of overly sensitive people defending Garadget here. Their basis -- that this customer was likely brought up wrong -- is a bit amusing. It suggests that the defenders were brought up to judge others based a single interaction, without any thought of context, or anything but the barest of social awareness.
Welcome to American culture. If you think this is bad, look at how parents judge other parents' parenting skills. Mom-shaming is one of the great American past-times. There are few cultures in the developed world with such a strong affinity for judging others. It's the root of the political climate, too: two people who might otherwise get along will, for example, often never have a second date once they discover they are from different political parties.
Shaming others is one of the basic acts of culture reinforcement. It's everywhere in one form of another, not just America. You might notice it here if you're a foreigner because what we shame might be different than where you come from.
Yes it is everywhere, but it definitely exists in different degrees among different cultures. Some societies show much greater preoccupation with other people's lives than other societies. Which is why some cultures are known as more "tolerant" than others.
Calling child protection services because other parents allow their kids to roam outdside without constant supervision is a whole different kettle of fish.
And yet roaming outside without supervision is perfectly accepted and safe in most regions of the U.S. (certainly not all), and the world. I can't tell if you are justifying a call to child protection services in such a case, or not.
I think that there is probably a large overlap between the population of people who believe this and the population of people that don't really know what bytecode or JIT compilation are.
In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors:
1. Its high level abstractions are computationally expensive. Sometimes this idea is supported by saying that garbage collection is very slow, sometimes by saying that the inability to directly manage memory means that it is done inefficiently, perhaps even inescapably so.
2. Compiling a program to an intermediary language that is not assembly but must be instead executed by something else (in this case, the JVM) must be slow.
Controlling memory layout is one area that is very important for performance, where Java does not exactly shines. You essentially have to store your data in arrays of primitive types, to avoid memory overhead of objects (pointer to class, lock, gc bits) and additional indirection during access. While not exactly impossible, Java makes it quite inconvenient and costly to write code that takes control of memory layout.
Hence why there are ongoing improvements targeted to Java 10, to change exactly that.
Until then there are the IBM and Azul extensions, off heap memory, or optimizing in native code that 1% after using the profiler, where it really matters.
1) Controlling memory layout is not as big a deal as people think. The JVM is highly optimized (really it's probably the most optimized system ever devised) for allocating and deallocating objects on the heap.
2) It is in fact possible to control memory layout today because Java has access to offheap memory where you can have all the control you want.
This has actually been the case for nearly half a decade but for some reason a lot of people are convinced that "big arrays" can knock over the JVM.
Only by those that don't have experience in Java tooling.
High startup costs you say? Then don't use OpenJDK.
Get an AOT compiler to native code like Excelsior Jet or switch to a JVM that supports both AOT compilation to native code and JIT code caching like IBM J9 or Azul.
class scanning ? Again stop using OpenJDK and switch to a JVM that supports class sharing across VM instances like IBM J9.
For those that don't want ever to use anything other than OpenJDK, some of those features might eventually come there, like the newly introduced support for AOT compilation of the base module for Linux x64. With everything else planned for Java 10.
Bloated libraries? Well, there are bloated libraries in any programming language.
And by any change you are thinking of JEE, I doubt you had the pleasure to use C or C++ alongside DCOM, CORBA and SUN RPC, at enterprise level to fully understand the relief it was to change to JEE.
Java is not slow in practice. Many top trading systems have been written in it, including the excellent and widely licensed nasdaq architecture (omx, singapore, asx, swx, etc) and the independently designed Lmax Disruptor. You do not have to use any library you don't want to. there is nothing stopping you from building everything in preallocated byte arrays, and never triggering gc. Nio2 is fast. Jvm is a leading foundation of fast, complex distributed systems, particularly if you need multiple programmers working on a single source tree.
In my experience NASDAQ's system is both a stellar example of law-latency Java and, due to its rarity, a demonstration of the apparent difficulty. Every other trading system I have seen implemented in Java has suffered noticably from poor memory management (too much GC-related variance). I would expect that Nasdaq approaches their trading software much more like an embedded system, at which point the engineering discipline and mastery of the playform matters much more than the language.
Also as mentioned elsewhere in the thread, trading systems don't suffer from frequent cold restarts, so hotspot work amortizes extremely well. So Java is much more optimal there than e.g. a command line tool.
Yes Java is as quick as anything else once it is up and running; the point GP was making was getting to this warmed up state is what makes people perceive java as slow.
A situation that only occurs if one doesn't make use of JVM that cache JIT code like IBM J9, or willing to pay for an optimizing AOT compiler like Excelsior JET.
Also another example is those that perceive the JVM as slow due to using it with Clojure, when the slowness in this case is caused by the Clojure implementation itself.
Aren't you great. As a java developer I am well aware of them too. For most people java == java applets; or "hello world" with `javac Hello.java` and then `java -cp. Hello` followed by some interminable wait while all the apparatus of the JVM is marshalled for the sole purpose of emitting a static string and then exiting. And by interminable I mean 2 or 3 second but still.
Even in more enlightened scenarios a REPL on jruby is just eye-wateringly painful unless you've all the "secret speedups" enabled.
In many more modern development cultures such secrets are generally looked upon as "Yak Shaving".
The reputation for slowness comes from the warm-up time. There is always a very noticeable delay starting even a simple java app; whereas a native binary is relatively instantaneous. There are tricks to alleviate this issue in java (e.g. you can keep a JVM running in the background using tool like nailgun) but the default vanilla java behaviour is what most people will be familiar with.
Most likely there are already processes in place to get down to the truth on matters like these. Slow-moving processes - but processes, nonetheless. You know - formal appeals, FOIA requests, lawsuits, expert testimony - that sort of thing.
But this all makes for poor ad copy, of course. "Bold, Crafty Innovator Thwarted, 'Cause Unions!" -- that's what gets people to click on your article. And share it in venues such as this one.
The problem is that all those things cost money, and the "bold, crafty innovator", after putting $1M of his own money into it, can't afford to pay for all that. The city, and the union, have very deep pockets, and have no incentive to do the right thing and pay for it.
I'm not saying he has no reason to find fault in either the DOB's initial decision about his new crane, or in Crain's coverage of the issue.
Just that it's kind of weird (in my view) that so many people seem to be happy to conclude that we somehow "know" that it was union arm-twisting which (at least temporarily) sealed his fate. Despite the complete lack of primary (or even secondary) evidence for such a connection.
I'm late 30something and I do not want to be writing code any more. I'm burnt out, thanks to being an Android developer. (Don't do it!)
I'm not sure what I'll do instead. I've been reading a bunch of stuff folks have written about the subject, but most people are focused on going in to management or QA or whatever. I think I'd just like "out". My brain ain't what it used to be and I'd rather quit than be fired, if you get my meaning.
I don't have an answer yet. I half-joke about becoming an Amazon Flex driver.
The APIs are not great. Some of it is down to poor naming, for example:
The callback you'd use on a CheckBox is called `OnCheckedChangeListener.onCheckedChanged(view, boolean)` (or something) but it is called whether or not the check state actually changed (e.g. if you call `setChecked(true)` and it's already checked you'll get the callback anyway). This is an issue that plagues the APIs in other places like `OnLayoutChangeListener` and `TextWatcher.OnTextChanged`
The fragment lifecycle is incredibly complex to the point that many people advocate against using it -- I'm one of them. It's like someone decided to try to solve every problem ever without asking the real users (devs) what they thought was wrong.
But the worst thing about it, bar none, is just how long it takes to build and run an app. We're talking 1.5-2 minutes. Everyone has their pet idea for reducing the build/test cycle but they provide marginal benefits at best and don't offer up concrete examples with concrete data (e.g. "I am running this gradle command for this github project on this computer and am measuring it this way, and here are my results"). I've spent weeks of time, scattered over the years, trying to figure out a way to reduce this to something more reasonable like 5 seconds, but to no avail.
My best guess is that other people are working on tiny toy apps or are just building the default project and then proclaiming that I must be mistaken, I must be doing something wrong for my build (of a reasonable sized app) to be as slow as it is.
I look at these previews as an example of things to come 3 years from now.
I keep hoping that Google will figure out a solution to that (restrict access to Play Services, say). Until then, I guess I'll continue targeting API 16.
Until then, I guess I'll continue targeting API 16.
I started targeting API 19 (4.4, KitKat) over a year ago and have never looked back. That encompasses the vast bulk of Android users (>85%) and encompasses almost all of the significant developer improvements. Even using the absolute latest fun such as multiple windows is an absolute breeze from the development side, regardless of many users not supporting it yet.
As a side benefit, the devices that get excluded are often older, often abandoned devices. I previously tried desperately to support all of those older devices and the reward were a barrage of low ratings by people on poor performing old devices.
Android has a planned obsolescence thing. I've gotten use to it.
It's a virtuous circle for sure, however there are very decent sub-$200 devices now with Android 6.0+ (many set to receive 7 in the next couple of months). And on the contract side, many consumers are just accustomed to getting a new device every two years regardless, seeming "free", albeit baked into their service fee.
At some point the market will settle as the pad market did, however right now the lack of pressure on vendors to support upgrades is also a reflection of a user base that is accustomed to constantly upgrading (better cameras, processors, storage, etc).
That would just make them look for alternatives asap.
The basic problem is that updates are an expense once the SKU starts shipping, while spending the same money on a new SKU is an investment.
Apple get around this because they own the whole stack. Thus keeping a device going longer means more exposure to their stores.
Never mind that even though they release a new iOS in name, major new features are left out for the version pushed to the older devices.
Never mind that on Android APIs can be supplied by APKs, and thus we have Play Services.
Frankly the only thing Google can do is adopt something akin to what they have on ChromeOS.
Split the Android VM layer from the Linux layer, so that they can update the VM layer independently of the kernel and userland layer.
Another issue is unless you are looking at white box rebrands, each OEM tailor the Android UI/UX.
Unless Google makes it possible to isolate this tailoring from the core Android code, there will still be lag time between Google releasing a new version, and it hitting devices. And that is reliant on the tailored variant fits inside the storage space of the device.
> Never mind that even though they release a new iOS in name, major new features are left out for the version pushed to the older devices.
This is simplistic and largely wrong. Only when there is a lack of appropriate hardware e.g. noise cancellation in the A5 chip or inadequate RAM has Apple decided not to port to those older devices. It's not a deliberate policy especially since they have been selling older devices alongside the newer ones.
That said for developers it's been about 99% of features available on all devices.
Yes, Apple is much better about it; but there are instances where Apple has limited certain features to newer devices when there was no real reason for doing so. Most recently they blocked trivial features such as content blocking and Night Shift from 32 bit devices in their push for 64 bit adoption.
That is the solution, the contract for accessing Play Services already has quite a few clauses, requiring updates would just be yet another requirement for accessing Play Services.
If you are still targeting 16, you should make sure that you are handling a bunch of pretty serious security changes made between 17-21. There are a lot of ways you can shoot yourself in the foot when using the old APIs.
IANAL, but I don't think HIPAA applies. As I understand it, HIPAA only applies to doctor/patient interactions, not situations where the "patient"[1] is looking for data independently.
[1] patient is probably the wrong term here, without a doctor/nurse directly involved
My health system in Oregon is offering online consultation with medical professionals. I haven't used it yet but it seems more than email and it seems person to person, not person to medical journal article.
You (and malikNF) are acting like Waterluvian was saying all Linux is bad, when that couldn't be further from the truth. Waterluvian is saying that simply choosing to switch to Linux doesn't automatically mean you'll get away from bullshit.
* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.
* Allow the user to collapse a thread so they no longer see it in-line.
* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).
* Allow the user to navigate between threads using only their keyboard.
As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).