Flip the question around: Is it ok to lay people off without paying severance?
Same answer as original question: Yes
IMNSHO, you should always have a plan in place to protect yourself financially in case of a sudden layoff / termination. Preferably 2. That means you should spend less than you earn, and live below your means, and save save save.
[Play in 2009] was the most light-weight, most non-obscure of all the Java frameworks.
confirms everything said about you in ancestor posts.
Now, can you find another source that agrees with your moronic 10:1 advantage?
It was clearly stated as being a comparison of 2 systems. Could the.NET system have been rebuilt to follow the better "best practices" of the Java design? Sure. But unless it went hybrid, it would never compete, as the core data services ran on big iron and wintel had nothing even close in the ballpark, something about 4 CPU systems being the max at the time. So if you believe even 40 windows boxes could keep up with a single AS400, well, we're done then, because they can't in the domain in question. Again, this goes to big data and high concurrency, combined, something you still seem to have trouble digesting.
[I reviewed Play a few years ago...] not least of which was obscurity
Obscurity? You have to be kidding me.
You're going to argue that Play in 2009 was not obscure? Your audacity is mind-boggling.
So you clearly know a lot more than the creators of the Play framework. You can go here and see what the Play framework creators think that they them selves did, but hey, you probably know best. Play comes with Twirl, a powerful Scala-based template engine, whose design was inspired by ASP.NET Razor. Does it hurt to be that dumb?
You tell me. We were discussing Play pre-releases and Play 1.0, not Play 2.5 from 6+ years later. FYI "moving the goal posts", what you're attempting to do here, is a sign of a losing argument. Just admit you're wrong and we'll be done. In case you can't do that, why don't you tell us when Twirl was added to Play and how that relates to my statements about Play up to release 1.0.
you were processing a multi-million row complex data set on the fly for every query?
Talking about reading comprehension...Imagine processing a certain type of performance data every 15 minutes. This is the monstrous data set. As part of that processing, you are required to enrich certain records with data retrieved at the beginning of the fifteen minute interval from an external source. One where you have no ability to control the result set size. Was that difficult to comprehend? That data must be processed, in memory, prior to you being able to do any form of data enrichment. Was that difficult to comprehend? Again, have you ever worked with external data providers?
Not exactly a high-concurrency large data set system, now is it? My statements above, and throughout, have not been about either/or, it's both. Either scenario by itself, while presenting certain challenges is nothing really compared to a combination of both. Should you graduate from bottle feeding you'll figure out that anything you can hold in memory in a single system is NOT large data. What you're describing is simple feed processing that barely registers as a task.
Setting up a simple searchable data polling proxy service, however, should take you all of a couple of weeks, tops
You have clearly never worked with the government. It can't do anything in "a couple of weeks". A couple of years, perhaps. The big telcos are similar, or at least were ten years ago.
I didn't say anything about them, I clearly stated "you". I integrated with several external sources for exactly this type of data just a few months ago. Each service (my side) took a couple of weeks. I required no changes on their side. On this system we service 1000s per minute with latencies in sub 50ms compared to a service that at most can handle 10/minute with minimum 500ms latencies, and I'm not the only client of this admittedly non-gov entity. I wish they were as responsive as the gov, actually. I might see progress every now and then. You truly have some weaknesses, both professionally and personally. You remind me of that guy I ran into that used to work for Amazon and fancied himself an architect. He's no longer allowed to do anything that touches production systems.
Moron.
So once you learned what pretentious means you dropped your argument that you aren't. There may be hope for you yet. Perhaps learning what moron means next will allow you to properly use it in the future, because from this thread, I'm pretty sure you don't comprehend its actual meaning.
No, that's not why you restricted it to just DBs. You restricted it to DBs because you are ignorant. You don't use Linq2SQL in your app. It's that fucking simple. Not if performance is important.
So from your statements, you don't use linq for DBs, and you don't use linq for performant code. So linq is generally useless according to your own statements for the class of systems we're discussing. Glad we got that out of the way.
Conversely, where interesting stuff was done in.Net, Java developers picked it up. The Play Framework v1 is basically what you would get if you port the good parts of -NET MVC to Java.
I reviewed Play a few years ago and found it wanting for a variety of reasons, not least of which was obscurity at the time. However, you might want to correct who took what from whom. A quick review of history shows Play pre-releases preceding the.NET MVC framework pre-release, and v1.0 was released a year prior to.NET MVC 1.0. The only statement I'm making is that your statement implying that Play ported anything from.NET is a complete fallacy.
yet you failed to comprehend what that example was telling you
No, it told me plenty. All of it about you. You have no experience with larger systems.
Sure it did. Your level of reading comprehension dwarfs your IQ, apparently.
You have no experience integrating with external systems over which you have no control. Here is an example of your mind-boggling in-experience. Your comment "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory". I even told you why this was necessary but you simply have no experience with integrating with external systems. You therefore have never been in a situation where you have no choice. The service I was specifically talking about above was an external government (non-US) service which we could query for information vital to our system. The service had no search facilities, it had no possibility of limiting the data set you pulled down. In other words, we had no choice but pulling the data down, and it had to be real-time and do the filtering in memory. It took us seven years to get them to put an API in place and it would have taken us another five to get them to make the data searchable. You have clearly never attempted to gather data from data sources that were not your own and that you therefore had no control over whatsoever.
You're misleading at best, or lying at worst. Let me get this straight: you were processing a multi-million row complex data set on the fly for every query? From a government data set? Right. Oh wait, you had single queries per hour across a tiny data set? Because I can't imagine you were processing 10s of thousands of requests per minute on data that was as monstrous as you imply from any government's service. Setting up a simple searchable data polling proxy service, however, should take you all of a couple of weeks, tops. But why am I telling you that? You obviously know everything there is to know about large data sets and high concurrency.
Yes, obviously. Microsoft released Linux on Azure in 2013, after it having been available in Beta since late 2012. So, when did Apple launch the iCloud on Azure? 2011.
Apple stored encrypted files on Azure in 2011 according to some docs released in 2014. Not exactly what you're implying but hey, what's a few facts compared to an invective laden superiority complex rant?
If I was pretentious I would have to make positive statements about something.
Why would that be worse than the uncountable number of mutants that crop up all of the time?
So, according to your line of thinking then, why bother controlling pollution, since uncountable tons of pollutants are expelled all the time (via volcanoes)
Eaten trillions of times, zero demonstrable human health effects. That doesn't mean we stop looking, but how much testing would be enough for you to stop worrying?
Roundup - eaten trillions of times, and now we see a problem.
But that's not really my point. My point is that GMO is a process, like creating new organic compounds, not a product. Every product should be individually approved.
Sigh. That's not what the article said.
Try reading it. Apparently the effects are there at low concentrations. It's not like a smoking gun over a corpse, but the study certainly raises some questions about the assumed safety of the product as currently used.
Instead, it's nearly all incoherent rants about how "frankenfood" is not what "mother nature" intended for us to eat.
Mine's more concerned with an unintended and will almost never occur in nature genetic hybrid getting out and turning out to be bad. For instance, I'm 100% for genetically reverting the 3 human biting mosquitoes to previous non biting incarnations, undoing millions of years of evolution. Now that would truly be a bit of magnificent and beneficial genetic modification.
Note that it was centuries before tobacco was deemed unhealthy. Beef and alcohol even longer. Wood smoke, bad. Some things were found out more quickly, recall thalidomide? It was perfectly safe before it... wasn't. GMOs have to be proven safe one at a time, every time. The process can never be proven safe, because that same process can create the next pandemic disease just as easily as the cure for it.
I'm still undecided on whether Monsanto's soybeans are safe or not. There simply hasn't been enough testing over a long enough time, and there's been too many variables surrounding a variety of trends since those soybeans started being grown. What's not in doubt, however, is that Roundup itself is quite bad. It turns out an inert ingredient is actually maybe not so inert, as it negatively affects health. It only took us over 21 years to figure that out. Maybe it's too soon to determine if the soybean GMOs are actually safe as well? Maybe GMOs that use genes from outside their genus or sub-family should require the same FDA process any man-made chemical requires to be approved for human use.
I don't rant and rave, I don't point to alternative medicine websites or random blogs. I merely look at the facts and see that perhaps all is not as safe as the industry that stands to directly benefit from GMOs says it is. They would, after all, never lie, right?
it pretty much fails to deliver as soon as you get to anything interesting
Could you elaborate please? Again, keep databases out of it, Linq is not a database framework. The fact that you continue to compare Linq to Hibernate shows you think Linq is database related, which just shows your ignorance. Linq has nothing to do with databases.
I'd quote your "You're a moron" but it doesn't do justice to your statements.
You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory. That's why I restrict linq discussions purely to DBs, because any other use in what I do would be flat out stupid and the road to failure. If you don't see that, your project will probably be one I, or someone like me, will have to come rescue in the near future.
So you are not comparing Java to C#/.Net. They two are close to identical in base features, so it is impossible to make a Java app that is more modular than you can make a.Net app. What you are saying above is that you are comparing the code of a bunch of morons who could not make a modular app to the code of competent developers that could. That's the comparison of an ignorant moron.
ROFLMAO. If... no.
Sometimes bad architecture lays a crumbling foundation that just can't be corrected.
Yeah, but bad architecture is not a framework or language feature.
But some languages and features promote bad architecture. And some obviously haven't figured that out yet, and some never will.
A current startup project is still in testing stages, and tables are already touching 1M rows...
If each of those calls hit 5 tables...
So you are talking about relatively small systems with few tables and quite moderate amounts of data. OK. That may explain things.
That was a simple example, and yet you failed to comprehend what that example was telling you.
You simply haven't worked on teams where performance is an issue, you have had some straight-out-of-school kids do some stuff in.Net, and you think that you have worked on big data stuff. That's more than just a little sad.
Imagine an MPLS switched network with about 20 000 nodes, switches some servers etc. They are all SNMP managed, and they have 64 or 128 points each that regularly report status back to the NMS. On average approximatley once per hours at night, more during the day.In addition there is about 100 performance counters for each of the devices from which performance data is collected every 15 minutes, aggregated to hourly, daily, weekly, monthly and yearly aggregated values. The data collection alone means about 10 million inserts into the database every hour. Stored procedures aggregate these values, and they are presented as close to live as possible in various dashboards. That's not a very large system, it is bigger than the bookstore example you provide, but it's not one of our bigger installations. It runs entirely on the.Net platform and it's not even close to breaking a sweat.
Let's look at another one, one that you are maybe familiar with. It's called the iCloud. You know, the infrastructure on which Apple is relying to serve all of its Apple Mac and iDevice customers. Apple didn't have the infrastructure in place to build their own, so they out-sourced it. To Microsoft Azure (and also to AWS). Azure is built onw which platform again?
You're a moron.
I was doing that back in 2000. Are you using my code? That was almost a trivial amount of throughput even back them (DB limited). I have since written simple systems like that to support reporting that handled 50K multi-stage transactions and 500K inserts per minute for entirely different systems. Those were generally trivial solu
I like the position that prior to any H1-B being actually given out the gov does its own US worker recruiting. If the gov finds a US worker qualified for the intended H1-B position, the company gets the US worker, and that H1-B position gets marked "filled" (i.e., 1 less H1-B granted but marked as an H1-B for counting purposes)
Yeah, Linq, the initial spell check marked my typo as an error, and after a failed google-fu that only popped up LYNC, I changed it. It happens.
While linq makes great promises, it pretty much fails to deliver as soon as you get to anything interesting, and this is not unique. I've seen the same with hibernate, JPA, and several other flavors of these "helpful" frameworks. When it comes to large data sets and high performance, these "helpful" frameworks have, in my experience, always worked against you. The worst case of Hibernate vomit I ever saw was several 100K of custom code merely to deal with object relationships that Hibernate couldn't handle any other way. To be honest, I used to be a Hibernate proponent long ago, until my own codebase's custom code exceeded 25K LOCs just to handle the ever increasing complexity as new features got added over time. We stopped, rearchitected the DA, and 5K LoCs later (and about 3 months) replaced the entire Hibernate mess with a sensible base framework that was not only easier to deal with but faster and safer, as we had also uncovered a possible injection attack or two in the old codebase while converting it (Yes, Hibernate still won't save you from a developer's bad code) You might ask, what did we lose? Yes, we lost the ability to just plug in another DB. Whooppie shit. Guess how often I've needed that feature and a framework handled it? Not once. And to answer your obvious next question, I have multiple projects in my career that supported pluggable DBs. Not one used these frameworks.
Lambdas? I haven't seen where they are significantly better than other simpler solutions. They save you typing a few characters and a couple of braces. Considering most of that is handled by the IDE, what, exactly, is it providing me? Oh, and we've had the ability to work with closures in Java since hmmmmm... anonymous classes were introduced. They had a couple of extra stipulations, but you could functionally create them. Apparently typing 5 characters and a space was too much for some programmers.
Outperforming statement: 60 Java servers plus 20 AS400 systems carried significantly more work load than more than an 1800 windows based set of servers doing less actual functional work (competing companies, I happened to deal with both). That's a greater than 10:1 difference. I can't get any more specific than that. You can accept that statement as is or not.
Updating the apps: the difference was in architectural design decisions. The Java app was far more modular, with features being able to be added to a module without affecting anything else. The.NET system was monolithic, both by design and necessity according to their architecture team. I've never had the option to see if there was a better way in the.NET world as the projects I was involved with were tweaks to improve bits or wholesale redesigns because you would spend more time trying to refactor code than you would rebuilding the entire system. Sometimes bad architecture lays a crumbling foundation that just can't be corrected.
You'll note through your condescension if you read through the end that all those extra frameworks are just fine for simple bookstore apps. When you scale systems up for large data and/or users in significantly more complex systems than a bookstore app, performance is always important. A current startup project is still in testing stages, and tables are already touching 1M rows. It's not even live yet, when they'll easily explode by comparison. An extra ms in a function can mean a lot in that type of scenario. There is a frequently used lookup function that pulls hundreds of multi-table records in sub 100ms times under load. If each of those calls hit 5 tables and each table call required an extra ms to execute, I could close up shop today. BTW, that's exactly what finally drove the approval to re-design a linq system to remove linq, linq was just adding too much time to the calls and couldn't be optimized any further. Several tables exce
Opinion discarded. You're blinded by your own hatred of Comcast and your vision of how you want things to be rather than truly analyzing the situation and paying attention to reality.
Seriously? You think Comcast is working out well and that is a perfectly sensible business model? You would argue that separating the natural monopoly pieces such as actual cabling and purely competitive services such as content providers is not a positive end? Way to stick up for corruption! Next you'll be telling me I should be happy I'm only having to pay $100/month, and that $200/month would be better, and $500/month would be showing my support! And don't be a commie by not paying at all.
I am rather well-known for a long history of being at the leading edge of technology and often even serving as a guru for emerging technologies.
So you're essentially a jack of all trades and master of none, ever looking for that silver bullet or unicorn and have no real expertise to offer? It explains much about your situation and resulting world view. Always have a solid fallback by being an expert in something. Keep your nose aligned on trends, and if your chosen fallback is dropping out of favor, it might be time to become an expert in its replacement. And stop chasing unicorns.
Until the truck has a blowout (Which happens regularly), a mechanical fault happens (also happens regualrly), a senosor fucks up (happens even more), there' rain, fog, snow or dirt (Basically daily) to start.
Got a solution to the above? Let me answer for you - no you dont. Autonomus trucks are a bigger fucking pipedream than autonomous cars - it isnt going to happen fo 30 years at least.
Try 5 years, highly likely. Blowouts will be less common, because, get ready for it, automated service on tires and brakes will generally catch the problems. Also, not having drivers fall asleep and skim jersey walls or wake up driving in the median and rolling over a bunch of tire damaging junk will also reduce potential tire damage. Lower speeds will also lower tire blow out risk and brake issues. In fact, because the autonomous vehicle can't be hurried, isn't impatient, and won't fall asleep, truck accidents will likely drop significantly. Oh, and lower speed will also allow for much shorter stopping distances in case something goes wrong.
There would be a lot less corruption if the FTC followed a simple rule: if you have 10% or will have 10% of any market due to a merger or acquisition, you may not merge/acquire. A very simple rule that aims for keeping competition in the market place. Given the current conditions, we may have to start at 30% or something like that, and force some current effective monopolies to change their business practices (Comcast et al) but I see only positives coming out of that.
Amazon I have no issue believing. They market their own stuff all over the place, and geez, Prime this, Prime that, Prime everything. Not Prime? Too bad for you, you pay this other greater amount and your shipping will be done no sooner than 5 days from now.
Apple does seem to be causing Spotify some grief but until I have details, it may just be Apple being Apple about something Spotify is doing. Pandora, after all, seems not to have any issues.
Google does abuse its position in the search engine / advertising world, but Google Plus? Really? That's like saying Lyft dominates the US alternate taxi cab market.
The tablet is a whole lot easier to browse the web on or do a whole host of other things. I'll use my phone, but if my tablet is available, I'll use that over the phone. If a laptop or other computer is available, I'll use those for web browsing. There's just no substitute for multiple tabs and flexible cut and paste and general actions taken on a computer browser versus the experience on a phone or tablet. The thing is, tablets appear to last at least twice as long as phones, at least from what I'm seeing in the Apple realm, and apparently the Nexus tablets appear to be lasting longer than the average Android phone.
I still love iPads, I just haven't had a need for a new one in 5 years. My 2011 iPad2 still serves me just fine and I use it almost every day for looking up data during meetings at work and couch surfing and playing games at home or watching movies when traveling. When it finally dies I will definitely buy another, if not sooner. The iPad Pros have been calling my name lately.
The reason the folks switched from.NET were precisely productivity, reliability, scalability, and we can add ongoing maintenance costs
This is pure nonsense. I did Java for the Enterprise from 1997 through 2006. I worked for one of the first companies in the world that had significant product for the Telecom world written in Java. Back then we could not inform our customers it was Java since Java was perceived as too slow for our market segment. A colleague of mine wrote an SNMP stack at the time that was at least two orders of magnitude faster than any other stack out there. I struggled with CORBA when the Iona C++ ORB would not talk to the Iona Java ORB.
Since 2008 I've been doing about 20% Java, 60% C#/.Net and the rest a combination of Ruby, C and some Scala. C# blows Java out of the water in every single way. Tooling is heads and shoulders above what Java developers have wet dreams about. Scalability is certainly not inferior to Java in any way. The C# language has been significantly better than Java since 2008, and the distance between the two is increasing. Ongoing maintenance cost for.Net is significantly below what it is for.Net. I've spent more time on digging apps out of the horrendous monstrosity that was EJBs and J2EE than I have been actually adding features. I am soon done moving an EJB/Seam/Java/Hibernate/ app to.Net using mostly WebAPI and Angular 2. Adding features to the new app is done with half the resources in less than half the time compared to the old app. I'd say at least 50% of that is caused by the tools and the technology used, the other half is the over-engineering by the previous developers.
Java is playing catch-up, but it is playing catch-up-by-committee. It's not catching up.
Where to start? OK, let's start with that I fully switched from the C/C++ world to Java in 98. It was a little clunky back then, but fast enough. I've seen.NET solutions that use 10X or more the resources used by equivalent Java systems. I've converted.NET programs to Java, which ran faster and cleaner after conversion. Tooling? What tooling? If you're talking about LYNC, what a pile of shit that is. Is it better than Hibernate? The answer to that question is "Would you rather be shit on by an elephant or a mammoth?" In the choice between those two, I'll take what's behind door #3, thank you.
EJBs are anathema to productivity, performance, or anything else. I personally wish they'd never been thought of or given a name, as they are just about the worst thing you could possibly try to code and maintain. MFC spaghetti code intertwined with a CORBA bus or two might be more pleasant. Seam is another thing I don't think is very useful. You'll also be shocked that I am of the opinion that Spring sucks rocks too.
J2EE itself has a few useful pieces, but at this point, I only use some base frameworks and the application servers themselves. The rest is custom business logic (the value to the company) and a light framework, if necessary.
I'll state this much: I have had the opportunity to see a pair of systems that did the same function, one written in.NET by experts in.NET compared to a Java system written mostly by younger programmers, not all of whom were Java programmers. The Java system easily outperformed the.NET system by a factor of 10:1, was updated multiple times for each.NET update cycle, and was more capable than the.NET system. Both systems were in the millions of LOCs and performed tens of thousands of transactions a minute at peak. The Java system isn't a fluke. I've worked on quite a few large scale high transaction systems, all written in Java. I'm semi embarrassed to mention I've also written some "secure" C# appliances (AFAIK, they haven't been hacked yet) that were a bear to make work corr
Not to mention I would guess most people don't own an electrostatic discharge mat or cable for their arm. When you open these electronic without those safeguards you can shorten the life of the electronics. Unless you can prove you took all the safeguards and didn't cause any additional damage then the manufacturers should have every right to void your warranty.
I'd have to agree, sadly, that in the case of warranties, the manufacturers are correct in their stance. I do own an electrostatic discharge mat and cable, and have done more than my fair share of digging through various computers. However, I think manufacturers should not discourage tinkering once you're out of warranty, or you release them from warranty repairs. You can't have it both ways, keeping them on the hook while you root around and potentially break things.
Your newer Apple stuff is Wintel crap. Has been for years.
Funny, my 2006 Intel MacBook Pro doesn't have any MS software on it at all, and is still in daily use. Although I do freely admit it is on its last legs, but only because I cannot update it past 10.6 and get more than 3GB of RAM in it.
First, the health care industry now has to hold massive amounts of data on you, and has to make it available to the Government. This is the price of government mandated and controlled insurance.
They've always done this. And it's always been available to the government. They might have needed a warrant, but it's available.
Your reading comprehension leaves something to be desired, or there's something worse afoot with you. To make this absolutely clear, I stated the following:
They've always done this.
to clearly and, yes, pedantically state what that means, since your comprehension of said quotes above seems severely lacking this can be transformed into a plain fully qualified self-standing sentence:
The health care industry has always held massive amounts of data on a patient
I do not believe there's any question that they've done this for most of the past century (as in 100 years). This is not a current thing. Have you not visited a health care provider over the past several decades?
Since this data exists, and has existed, are you arguing that somehow it was not available to the government? If so, please make your case. I'd love to read in what bizarre universe documents held by a non legal third party are not subject to a warrant in the US. In fact:
Which granted isn't an authoritative source but certainly lends some credence to the fact that you need to support your assertions as the implication is that HIPAA is the exact opposite of your stance. You can also see that earlier, the Federal Rules of Evidence, which became law in 1975, do not have any provision for privacy of medical records nor Physician Patient privileges. I have no idea what this imaginary Patient Client law is.... Perhaps you could cite it?
So, are you wrong, an idiot, a troll, or something worse?
That would be an invalid patent, per the PTO's description of a valid patent, IIRC (IANAPA, but:)
Section 112 of the Patent Act states
“The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.”
And what I was intending to describe by "built upon" patent was the original patent, then extended by the follow on, that the original patent would become public domain immediately upon filing of the follow on patent. Obviously the follow on patent improved upon the original significantly enough to warrant a new patent, rendering the original relatively worthless by comparison. Otherwise, the original would be enough, and the follow on is only an incremental improvement not worthy of a patent.
Slashdot Mirror
Flip the question around: Is it ok to lay people off without paying severance?
Same answer as original question: Yes
IMNSHO, you should always have a plan in place to protect yourself financially in case of a sudden layoff / termination. Preferably 2. That means you should spend less than you earn, and live below your means, and save save save.
[Play in 2009] was the most light-weight, most non-obscure of all the Java frameworks.
confirms everything said about you in ancestor posts.
Now, can you find another source that agrees with your moronic 10:1 advantage?
It was clearly stated as being a comparison of 2 systems. Could the .NET system have been rebuilt to follow the better "best practices" of the Java design? Sure. But unless it went hybrid, it would never compete, as the core data services ran on big iron and wintel had nothing even close in the ballpark, something about 4 CPU systems being the max at the time. So if you believe even 40 windows boxes could keep up with a single AS400, well, we're done then, because they can't in the domain in question. Again, this goes to big data and high concurrency, combined, something you still seem to have trouble digesting.
[I reviewed Play a few years ago ...] not least of which was obscurity
Obscurity? You have to be kidding me.
You're going to argue that Play in 2009 was not obscure? Your audacity is mind-boggling.
So you clearly know a lot more than the creators of the Play framework. You can go here and see what the Play framework creators think that they them selves did, but hey, you probably know best. Play comes with Twirl, a powerful Scala-based template engine, whose design was inspired by ASP.NET Razor. Does it hurt to be that dumb?
You tell me. We were discussing Play pre-releases and Play 1.0, not Play 2.5 from 6+ years later. FYI "moving the goal posts", what you're attempting to do here, is a sign of a losing argument. Just admit you're wrong and we'll be done. In case you can't do that, why don't you tell us when Twirl was added to Play and how that relates to my statements about Play up to release 1.0.
you were processing a multi-million row complex data set on the fly for every query?
Talking about reading comprehension...Imagine processing a certain type of performance data every 15 minutes. This is the monstrous data set. As part of that processing, you are required to enrich certain records with data retrieved at the beginning of the fifteen minute interval from an external source. One where you have no ability to control the result set size. Was that difficult to comprehend? That data must be processed, in memory, prior to you being able to do any form of data enrichment. Was that difficult to comprehend? Again, have you ever worked with external data providers?
Not exactly a high-concurrency large data set system, now is it? My statements above, and throughout, have not been about either/or, it's both. Either scenario by itself, while presenting certain challenges is nothing really compared to a combination of both. Should you graduate from bottle feeding you'll figure out that anything you can hold in memory in a single system is NOT large data. What you're describing is simple feed processing that barely registers as a task.
Setting up a simple searchable data polling proxy service, however, should take you all of a couple of weeks, tops
You have clearly never worked with the government. It can't do anything in "a couple of weeks". A couple of years, perhaps. The big telcos are similar, or at least were ten years ago.
I didn't say anything about them, I clearly stated "you". I integrated with several external sources for exactly this type of data just a few months ago. Each service (my side) took a couple of weeks. I required no changes on their side. On this system we service 1000s per minute with latencies in sub 50ms compared to a service that at most can handle 10/minute with minimum 500ms latencies, and I'm not the only client of this admittedly non-gov entity. I wish they were as responsive as the gov, actually. I might see progress every now and then. You truly have some weaknesses, both professionally and personally. You remind me of that guy I ran into that used to work for Amazon and fancied himself an architect. He's no longer allowed to do anything that touches production systems.
Moron.
So once you learned what pretentious means you dropped your argument that you aren't. There may be hope for you yet. Perhaps learning what moron means next will allow you to properly use it in the future, because from this thread, I'm pretty sure you don't comprehend its actual meaning.
No, that's not why you restricted it to just DBs. You restricted it to DBs because you are ignorant. You don't use Linq2SQL in your app. It's that fucking simple. Not if performance is important.
So from your statements, you don't use linq for DBs, and you don't use linq for performant code. So linq is generally useless according to your own statements for the class of systems we're discussing. Glad we got that out of the way.
Conversely, where interesting stuff was done in .Net, Java developers picked it up. The Play Framework v1 is basically what you would get if you port the good parts of -NET MVC to Java.
I reviewed Play a few years ago and found it wanting for a variety of reasons, not least of which was obscurity at the time. However, you might want to correct who took what from whom. A quick review of history shows Play pre-releases preceding the .NET MVC framework pre-release, and v1.0 was released a year prior to .NET MVC 1.0. The only statement I'm making is that your statement implying that Play ported anything from .NET is a complete fallacy.
yet you failed to comprehend what that example was telling you
No, it told me plenty. All of it about you. You have no experience with larger systems.
Sure it did. Your level of reading comprehension dwarfs your IQ, apparently.
You have no experience integrating with external systems over which you have no control. Here is an example of your mind-boggling in-experience. Your comment "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory". I even told you why this was necessary but you simply have no experience with integrating with external systems. You therefore have never been in a situation where you have no choice. The service I was specifically talking about above was an external government (non-US) service which we could query for information vital to our system. The service had no search facilities, it had no possibility of limiting the data set you pulled down. In other words, we had no choice but pulling the data down, and it had to be real-time and do the filtering in memory. It took us seven years to get them to put an API in place and it would have taken us another five to get them to make the data searchable. You have clearly never attempted to gather data from data sources that were not your own and that you therefore had no control over whatsoever.
You're misleading at best, or lying at worst. Let me get this straight: you were processing a multi-million row complex data set on the fly for every query? From a government data set? Right. Oh wait, you had single queries per hour across a tiny data set? Because I can't imagine you were processing 10s of thousands of requests per minute on data that was as monstrous as you imply from any government's service. Setting up a simple searchable data polling proxy service, however, should take you all of a couple of weeks, tops. But why am I telling you that? You obviously know everything there is to know about large data sets and high concurrency.
Yes, obviously. Microsoft released Linux on Azure in 2013, after it having been available in Beta since late 2012. So, when did Apple launch the iCloud on Azure? 2011.
Apple stored encrypted files on Azure in 2011 according to some docs released in 2014. Not exactly what you're implying but hey, what's a few facts compared to an invective laden superiority complex rant?
If I was pretentious I would have to make positive statements about something.
Pretentious:
Why would that be worse than the uncountable number of mutants that crop up all of the time?
So, according to your line of thinking then, why bother controlling pollution, since uncountable tons of pollutants are expelled all the time (via volcanoes)
Eaten trillions of times, zero demonstrable human health effects. That doesn't mean we stop looking, but how much testing would be enough for you to stop worrying?
Roundup - eaten trillions of times, and now we see a problem.
But that's not really my point. My point is that GMO is a process, like creating new organic compounds, not a product. Every product should be individually approved.
Sigh. That's not what the article said.
Try reading it. Apparently the effects are there at low concentrations. It's not like a smoking gun over a corpse, but the study certainly raises some questions about the assumed safety of the product as currently used.
Instead, it's nearly all incoherent rants about how "frankenfood" is not what "mother nature" intended for us to eat.
Mine's more concerned with an unintended and will almost never occur in nature genetic hybrid getting out and turning out to be bad. For instance, I'm 100% for genetically reverting the 3 human biting mosquitoes to previous non biting incarnations, undoing millions of years of evolution. Now that would truly be a bit of magnificent and beneficial genetic modification.
Note that it was centuries before tobacco was deemed unhealthy. Beef and alcohol even longer. Wood smoke, bad. Some things were found out more quickly, recall thalidomide? It was perfectly safe before it ... wasn't. GMOs have to be proven safe one at a time, every time. The process can never be proven safe, because that same process can create the next pandemic disease just as easily as the cure for it.
I'm still undecided on whether Monsanto's soybeans are safe or not. There simply hasn't been enough testing over a long enough time, and there's been too many variables surrounding a variety of trends since those soybeans started being grown. What's not in doubt, however, is that Roundup itself is quite bad. It turns out an inert ingredient is actually maybe not so inert, as it negatively affects health. It only took us over 21 years to figure that out. Maybe it's too soon to determine if the soybean GMOs are actually safe as well? Maybe GMOs that use genes from outside their genus or sub-family should require the same FDA process any man-made chemical requires to be approved for human use.
I don't rant and rave, I don't point to alternative medicine websites or random blogs. I merely look at the facts and see that perhaps all is not as safe as the industry that stands to directly benefit from GMOs says it is. They would, after all, never lie, right?
it pretty much fails to deliver as soon as you get to anything interesting
Could you elaborate please? Again, keep databases out of it, Linq is not a database framework. The fact that you continue to compare Linq to Hibernate shows you think Linq is database related, which just shows your ignorance. Linq has nothing to do with databases.
I'd quote your "You're a moron" but it doesn't do justice to your statements.
You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory. That's why I restrict linq discussions purely to DBs, because any other use in what I do would be flat out stupid and the road to failure. If you don't see that, your project will probably be one I, or someone like me, will have to come rescue in the near future.
So you are not comparing Java to C#/.Net. They two are close to identical in base features, so it is impossible to make a Java app that is more modular than you can make a .Net app. What you are saying above is that you are comparing the code of a bunch of morons who could not make a modular app to the code of competent developers that could. That's the comparison of an ignorant moron.
ROFLMAO. If... no.
Sometimes bad architecture lays a crumbling foundation that just can't be corrected.
Yeah, but bad architecture is not a framework or language feature.
But some languages and features promote bad architecture. And some obviously haven't figured that out yet, and some never will.
A current startup project is still in testing stages, and tables are already touching 1M rows... If each of those calls hit 5 tables...
So you are talking about relatively small systems with few tables and quite moderate amounts of data. OK. That may explain things.
That was a simple example, and yet you failed to comprehend what that example was telling you.
You simply haven't worked on teams where performance is an issue, you have had some straight-out-of-school kids do some stuff in .Net, and you think that you have worked on big data stuff. That's more than just a little sad.
Imagine an MPLS switched network with about 20 000 nodes, switches some servers etc. They are all SNMP managed, and they have 64 or 128 points each that regularly report status back to the NMS. On average approximatley once per hours at night, more during the day.In addition there is about 100 performance counters for each of the devices from which performance data is collected every 15 minutes, aggregated to hourly, daily, weekly, monthly and yearly aggregated values. The data collection alone means about 10 million inserts into the database every hour. Stored procedures aggregate these values, and they are presented as close to live as possible in various dashboards. That's not a very large system, it is bigger than the bookstore example you provide, but it's not one of our bigger installations. It runs entirely on the .Net platform and it's not even close to breaking a sweat.
Let's look at another one, one that you are maybe familiar with. It's called the iCloud. You know, the infrastructure on which Apple is relying to serve all of its Apple Mac and iDevice customers. Apple didn't have the infrastructure in place to build their own, so they out-sourced it. To Microsoft Azure (and also to AWS). Azure is built onw which platform again?
You're a moron.
I was doing that back in 2000. Are you using my code? That was almost a trivial amount of throughput even back them (DB limited). I have since written simple systems like that to support reporting that handled 50K multi-stage transactions and 500K inserts per minute for entirely different systems. Those were generally trivial solu
This is why the most reliable way of getting hired is bypassing HR entirely, and using your network.
I like the position that prior to any H1-B being actually given out the gov does its own US worker recruiting. If the gov finds a US worker qualified for the intended H1-B position, the company gets the US worker, and that H1-B position gets marked "filled" (i.e., 1 less H1-B granted but marked as an H1-B for counting purposes)
Separating the cables from the service is probably the best way to do this.
Yeah, Linq, the initial spell check marked my typo as an error, and after a failed google-fu that only popped up LYNC, I changed it. It happens.
While linq makes great promises, it pretty much fails to deliver as soon as you get to anything interesting, and this is not unique. I've seen the same with hibernate, JPA, and several other flavors of these "helpful" frameworks. When it comes to large data sets and high performance, these "helpful" frameworks have, in my experience, always worked against you. The worst case of Hibernate vomit I ever saw was several 100K of custom code merely to deal with object relationships that Hibernate couldn't handle any other way. To be honest, I used to be a Hibernate proponent long ago, until my own codebase's custom code exceeded 25K LOCs just to handle the ever increasing complexity as new features got added over time. We stopped, rearchitected the DA, and 5K LoCs later (and about 3 months) replaced the entire Hibernate mess with a sensible base framework that was not only easier to deal with but faster and safer, as we had also uncovered a possible injection attack or two in the old codebase while converting it (Yes, Hibernate still won't save you from a developer's bad code) You might ask, what did we lose? Yes, we lost the ability to just plug in another DB. Whooppie shit. Guess how often I've needed that feature and a framework handled it? Not once. And to answer your obvious next question, I have multiple projects in my career that supported pluggable DBs. Not one used these frameworks.
Lambdas? I haven't seen where they are significantly better than other simpler solutions. They save you typing a few characters and a couple of braces. Considering most of that is handled by the IDE, what, exactly, is it providing me? Oh, and we've had the ability to work with closures in Java since hmmmmm... anonymous classes were introduced. They had a couple of extra stipulations, but you could functionally create them. Apparently typing 5 characters and a space was too much for some programmers.
Outperforming statement: 60 Java servers plus 20 AS400 systems carried significantly more work load than more than an 1800 windows based set of servers doing less actual functional work (competing companies, I happened to deal with both). That's a greater than 10:1 difference. I can't get any more specific than that. You can accept that statement as is or not.
Updating the apps: the difference was in architectural design decisions. The Java app was far more modular, with features being able to be added to a module without affecting anything else. The .NET system was monolithic, both by design and necessity according to their architecture team. I've never had the option to see if there was a better way in the .NET world as the projects I was involved with were tweaks to improve bits or wholesale redesigns because you would spend more time trying to refactor code than you would rebuilding the entire system. Sometimes bad architecture lays a crumbling foundation that just can't be corrected.
You'll note through your condescension if you read through the end that all those extra frameworks are just fine for simple bookstore apps. When you scale systems up for large data and/or users in significantly more complex systems than a bookstore app, performance is always important. A current startup project is still in testing stages, and tables are already touching 1M rows. It's not even live yet, when they'll easily explode by comparison. An extra ms in a function can mean a lot in that type of scenario. There is a frequently used lookup function that pulls hundreds of multi-table records in sub 100ms times under load. If each of those calls hit 5 tables and each table call required an extra ms to execute, I could close up shop today. BTW, that's exactly what finally drove the approval to re-design a linq system to remove linq, linq was just adding too much time to the calls and couldn't be optimized any further. Several tables exce
Opinion discarded. You're blinded by your own hatred of Comcast and your vision of how you want things to be rather than truly analyzing the situation and paying attention to reality.
Seriously? You think Comcast is working out well and that is a perfectly sensible business model? You would argue that separating the natural monopoly pieces such as actual cabling and purely competitive services such as content providers is not a positive end? Way to stick up for corruption! Next you'll be telling me I should be happy I'm only having to pay $100/month, and that $200/month would be better, and $500/month would be showing my support! And don't be a commie by not paying at all.
I am rather well-known for a long history of being at the leading edge of technology and often even serving as a guru for emerging technologies.
So you're essentially a jack of all trades and master of none, ever looking for that silver bullet or unicorn and have no real expertise to offer? It explains much about your situation and resulting world view. Always have a solid fallback by being an expert in something. Keep your nose aligned on trends, and if your chosen fallback is dropping out of favor, it might be time to become an expert in its replacement. And stop chasing unicorns.
If there's no blowout, they're right.
It means they were lucky.
Until the truck has a blowout (Which happens regularly), a mechanical fault happens (also happens regualrly), a senosor fucks up (happens even more), there' rain, fog, snow or dirt (Basically daily) to start.
Got a solution to the above? Let me answer for you - no you dont. Autonomus trucks are a bigger fucking pipedream than autonomous cars - it isnt going to happen fo 30 years at least.
Try 5 years, highly likely. Blowouts will be less common, because, get ready for it, automated service on tires and brakes will generally catch the problems. Also, not having drivers fall asleep and skim jersey walls or wake up driving in the median and rolling over a bunch of tire damaging junk will also reduce potential tire damage. Lower speeds will also lower tire blow out risk and brake issues. In fact, because the autonomous vehicle can't be hurried, isn't impatient, and won't fall asleep, truck accidents will likely drop significantly. Oh, and lower speed will also allow for much shorter stopping distances in case something goes wrong.
There would be a lot less corruption if the FTC followed a simple rule: if you have 10% or will have 10% of any market due to a merger or acquisition, you may not merge/acquire. A very simple rule that aims for keeping competition in the market place. Given the current conditions, we may have to start at 30% or something like that, and force some current effective monopolies to change their business practices (Comcast et al) but I see only positives coming out of that.
Amazon I have no issue believing. They market their own stuff all over the place, and geez, Prime this, Prime that, Prime everything. Not Prime? Too bad for you, you pay this other greater amount and your shipping will be done no sooner than 5 days from now.
Apple does seem to be causing Spotify some grief but until I have details, it may just be Apple being Apple about something Spotify is doing. Pandora, after all, seems not to have any issues.
Google does abuse its position in the search engine / advertising world, but Google Plus? Really? That's like saying Lyft dominates the US alternate taxi cab market.
The tablet is a whole lot easier to browse the web on or do a whole host of other things. I'll use my phone, but if my tablet is available, I'll use that over the phone. If a laptop or other computer is available, I'll use those for web browsing. There's just no substitute for multiple tabs and flexible cut and paste and general actions taken on a computer browser versus the experience on a phone or tablet. The thing is, tablets appear to last at least twice as long as phones, at least from what I'm seeing in the Apple realm, and apparently the Nexus tablets appear to be lasting longer than the average Android phone.
I still love iPads, I just haven't had a need for a new one in 5 years. My 2011 iPad2 still serves me just fine and I use it almost every day for looking up data during meetings at work and couch surfing and playing games at home or watching movies when traveling. When it finally dies I will definitely buy another, if not sooner. The iPad Pros have been calling my name lately.
The reason the folks switched from .NET were precisely productivity, reliability, scalability, and we can add ongoing maintenance costs
This is pure nonsense. I did Java for the Enterprise from 1997 through 2006. I worked for one of the first companies in the world that had significant product for the Telecom world written in Java. Back then we could not inform our customers it was Java since Java was perceived as too slow for our market segment. A colleague of mine wrote an SNMP stack at the time that was at least two orders of magnitude faster than any other stack out there. I struggled with CORBA when the Iona C++ ORB would not talk to the Iona Java ORB.
Since 2008 I've been doing about 20% Java, 60% C#/.Net and the rest a combination of Ruby, C and some Scala. C# blows Java out of the water in every single way. Tooling is heads and shoulders above what Java developers have wet dreams about. Scalability is certainly not inferior to Java in any way. The C# language has been significantly better than Java since 2008, and the distance between the two is increasing. Ongoing maintenance cost for .Net is significantly below what it is for .Net. I've spent more time on digging apps out of the horrendous monstrosity that was EJBs and J2EE than I have been actually adding features. I am soon done moving an EJB/Seam/Java/Hibernate/ app to .Net using mostly WebAPI and Angular 2. Adding features to the new app is done with half the resources in less than half the time compared to the old app. I'd say at least 50% of that is caused by the tools and the technology used, the other half is the over-engineering by the previous developers.
Java is playing catch-up, but it is playing catch-up-by-committee. It's not catching up.
Where to start? OK, let's start with that I fully switched from the C/C++ world to Java in 98. It was a little clunky back then, but fast enough. I've seen .NET solutions that use 10X or more the resources used by equivalent Java systems. I've converted .NET programs to Java, which ran faster and cleaner after conversion. Tooling? What tooling? If you're talking about LYNC, what a pile of shit that is. Is it better than Hibernate? The answer to that question is "Would you rather be shit on by an elephant or a mammoth?" In the choice between those two, I'll take what's behind door #3, thank you.
EJBs are anathema to productivity, performance, or anything else. I personally wish they'd never been thought of or given a name, as they are just about the worst thing you could possibly try to code and maintain. MFC spaghetti code intertwined with a CORBA bus or two might be more pleasant. Seam is another thing I don't think is very useful. You'll also be shocked that I am of the opinion that Spring sucks rocks too.
J2EE itself has a few useful pieces, but at this point, I only use some base frameworks and the application servers themselves. The rest is custom business logic (the value to the company) and a light framework, if necessary.
I'll state this much: I have had the opportunity to see a pair of systems that did the same function, one written in .NET by experts in .NET compared to a Java system written mostly by younger programmers, not all of whom were Java programmers. The Java system easily outperformed the .NET system by a factor of 10:1, was updated multiple times for each .NET update cycle, and was more capable than the .NET system. Both systems were in the millions of LOCs and performed tens of thousands of transactions a minute at peak. The Java system isn't a fluke. I've worked on quite a few large scale high transaction systems, all written in Java. I'm semi embarrassed to mention I've also written some "secure" C# appliances (AFAIK, they haven't been hacked yet) that were a bear to make work corr
Then you have a problem on windows unless you construct your own sandboxed IPC processes.
Not to mention I would guess most people don't own an electrostatic discharge mat or cable for their arm. When you open these electronic without those safeguards you can shorten the life of the electronics. Unless you can prove you took all the safeguards and didn't cause any additional damage then the manufacturers should have every right to void your warranty.
I'd have to agree, sadly, that in the case of warranties, the manufacturers are correct in their stance. I do own an electrostatic discharge mat and cable, and have done more than my fair share of digging through various computers. However, I think manufacturers should not discourage tinkering once you're out of warranty, or you release them from warranty repairs. You can't have it both ways, keeping them on the hook while you root around and potentially break things.
Your newer Apple stuff is Wintel crap. Has been for years.
Funny, my 2006 Intel MacBook Pro doesn't have any MS software on it at all, and is still in daily use. Although I do freely admit it is on its last legs, but only because I cannot update it past 10.6 and get more than 3GB of RAM in it.
First, the health care industry now has to hold massive amounts of data on you, and has to make it available to the Government. This is the price of government mandated and controlled insurance.
They've always done this. And it's always been available to the government. They might have needed a warrant, but it's available.
Your reading comprehension leaves something to be desired, or there's something worse afoot with you. To make this absolutely clear, I stated the following:
They've always done this.
to clearly and, yes, pedantically state what that means, since your comprehension of said quotes above seems severely lacking this can be transformed into a plain fully qualified self-standing sentence:
I do not believe there's any question that they've done this for most of the past century (as in 100 years). This is not a current thing. Have you not visited a health care provider over the past several decades?
Since this data exists, and has existed, are you arguing that somehow it was not available to the government? If so, please make your case. I'd love to read in what bizarre universe documents held by a non legal third party are not subject to a warrant in the US. In fact:
Until 1996 there was no federal protection of privacy in medical records; and state laws varied widely. That changed with HIPAA.
Which granted isn't an authoritative source but certainly lends some credence to the fact that you need to support your assertions as the implication is that HIPAA is the exact opposite of your stance. You can also see that earlier, the Federal Rules of Evidence, which became law in 1975, do not have any provision for privacy of medical records nor Physician Patient privileges. I have no idea what this imaginary Patient Client law is.... Perhaps you could cite it?
So, are you wrong, an idiot, a troll, or something worse?
And what I was intending to describe by "built upon" patent was the original patent, then extended by the follow on, that the original patent would become public domain immediately upon filing of the follow on patent. Obviously the follow on patent improved upon the original significantly enough to warrant a new patent, rendering the original relatively worthless by comparison. Otherwise, the original would be enough, and the follow on is only an incremental improvement not worthy of a patent.