Also, per percentage of fires per number of units sold, Apple's products are significantly less likely to spontaneously catch fire. Hey don't flame me, it's actually true.
Although there is a difference between a product warning you to pull over and get out versus just exploding on your lap.
"compute" in a cloud context == "compute capacity". Think of it like first and last name. If I'm "Rob Jones", and someone calls me "Rob", it doesn't turn me into a verb.
Maybe this could allow for different form factor customizations. Think about how the phone part that requires FCC certification is a small brick completely encased in the equivalent of faraday cage except for where the external antenna plugs in. Then, this mechanism could create whatever kind of case/IO devices/instruments/ports/plugins where the comm brick just sits inside.
Then you can have a slideout and a standard ribbon cable connects it, and this slide out sits on the bottom of a chassis that also hosts the display, camera, speaker, microphone, port array and whatever else you want.
Think like the electric skateboard that all the different Tesla models are built on top of. Roadster, sedan, crossover, SUV doesn't matter. it all sits on the same skateboard that holds the important stuff for making the car move. Also could think of it as application engine and front-end UI, except as written in hardware.
Why is "Above" a douchebag just because they made a well reasoned conclusion based on clear-eyed observation of empirically verifiable data? I've seen similar examples and trends. I would tend to disagree with the conclusion that the motor is burnt out, but I do agree that LinkedIn has entered a different trajectory as far as growth and the value of being part of the network.
As a hiring manager I still use it to kick off searches, but I rely much more on face to face networking & direct requests of my network.
If I can do all this, why would I want to remain a tester? Why wouldn't I get into development?
Maybe you like breaking things, not building them.
Actually, I didn't break it, I discovered where it was already broken when it was given to me.
If I'm doing my job right, I build tools that automatically identify where something is already broken. Then we can use that tool to give actionable insight to the developer about where they strayed before they've swapped their brain to a new context.
I'd rather have 98% of the developers focused on application logic and a specialized 2% of the developers providing productivity improvements to the core platform.
The whole idea of writing crap code, and "optimizing" it later, whether with automated tools or by handing it off to others, works very, very poorly in practice. Putting a little effort in, at the start, to architect services properly, and keeping an eye on the design through the coding process, pays off in spades later on.
I never suggested that it was a good idea to write crap code. I suggested that it's a good idea to have some developers focused on things that all developers need to be taking care of (e.g. a platform that supports universal tasks). In that way, you raise everyone's efficiency with a single core effort and the vast majority of the team can focus on implementing features that move the business forward.
Not to pick too nittily, but your assertion that a load balancer should just "go[es] to the most responsive server" is kind of simplistic. When I was working there, we had a failure mode where the most responsive server was one that had tripped over a subtle bug causing all subsequent requests to that instance of the service to almost immediately respond with an http 200 and empty content (it was a bug, after all, and it was compounded by this failure mode of returning a 200). Because we used weighted round-robin, we were able to diagnose that only some of the servers were behaving badly and could focus on reproducing the problem, finding the root cause and fixing it. The short-term mitigation was to bounce the ones in a bad state as they got into the bad state. This was at the cost of a poor user experience for 1/n of current traffic. In your proposed model, all traffic would have black-holed into this highly responsive server possibly making diagnosis and mitigation more difficult.
As far as having to abstract away the heavy lifting of service management into a dedicated layer, I'm in violent agreement with that architectural decision. Without providing service management as a service, you put the burden on everyone's shoulders to manage it themselves. I'd rather have 98% of the developers focused on application logic and a specialized 2% of the developers providing productivity improvements to the core platform.
While it might be more rewarding for some to re-blaze trails that have already been explored (and improvements do come out of parallel efforts) it's a much better business decision to put as much weight as possible behind moving the product forward and leave the task of lifting the efficiency of the platform to a dedicated team.
Slashdot Mirror
What is this http://www.bricklink.com/ you speak of? Hm....
// looking
Oh crap. There goes my afternoon.
Wait! Are you saying that there's a sex with two penises?
Also, per percentage of fires per number of units sold, Apple's products are significantly less likely to spontaneously catch fire. Hey don't flame me, it's actually true.
Although there is a difference between a product warning you to pull over and get out versus just exploding on your lap.
> Right ... I'll tell Norway they own North America, ok?
Don't you mean Netherlands?
The cake is a lie.
"compute" in a cloud context == "compute capacity". Think of it like first and last name. If I'm "Rob Jones", and someone calls me "Rob", it doesn't turn me into a verb.
Maybe this could allow for different form factor customizations. Think about how the phone part that requires FCC certification is a small brick completely encased in the equivalent of faraday cage except for where the external antenna plugs in. Then, this mechanism could create whatever kind of case/IO devices/instruments/ports/plugins where the comm brick just sits inside. Then you can have a slideout and a standard ribbon cable connects it, and this slide out sits on the bottom of a chassis that also hosts the display, camera, speaker, microphone, port array and whatever else you want. Think like the electric skateboard that all the different Tesla models are built on top of. Roadster, sedan, crossover, SUV doesn't matter. it all sits on the same skateboard that holds the important stuff for making the car move. Also could think of it as application engine and front-end UI, except as written in hardware.
That was the most gratuitous, and yet somehow satisfying, execution of ITLAP Day.
Any person using FTFY or editing my postings disagrees to a US$50.00 charge
FTFY. HTH. HAND. IANAL. FUBAR. LMNOP. HHGTTG. YOLO. and last but not least, WITCOHEIBNFOPTDTPBWHCTWAATAATPOTETSAESTWTLONAONGETADRTTOOMRTTSDTCWITTTS
*There* is the comment I was waiting for.
Heck, lower the sidewalks to street level and when nobody is on them, use them as another place to drive!
It appears that you haven't been to Italy, have you.
Why is "Above" a douchebag just because they made a well reasoned conclusion based on clear-eyed observation of empirically verifiable data? I've seen similar examples and trends. I would tend to disagree with the conclusion that the motor is burnt out, but I do agree that LinkedIn has entered a different trajectory as far as growth and the value of being part of the network. As a hiring manager I still use it to kick off searches, but I rely much more on face to face networking & direct requests of my network.
Because then the kid might come back and form the Church of All Worlds, which would piss off the Fosterites.
Ok. Wait. You'd think that they would have allocated http://what3words.com/any.three.words to somewhere. But 404.
But you'd think that http://what3words.com/top.of.world would be something you could locate... it's also a 404
nice.finish.last == 404
Hurr Durr Herp Derp
Didn't you just mis-spell "Hodor!" ?
The currency of deluded people and unicoins.
There. Fixed that for you.
From the article: "starting with a particular type of cell removed from cow necks obtained at a slaughterhouse."
There was also a mention that there's an ongoing need for animal products to produce the growth medium.
There's work going on to be animal independent, but for now this meat is also slightly murderous.
If I can do all this, why would I want to remain a tester? Why wouldn't I get into development?
Maybe you like breaking things, not building them.
Actually, I didn't break it, I discovered where it was already broken when it was given to me.
If I'm doing my job right, I build tools that automatically identify where something is already broken. Then we can use that tool to give actionable insight to the developer about where they strayed before they've swapped their brain to a new context.
> Now if only someone could come up with a version where we could control the privacy a bit.
You have complete control over the visual privacy of your face in the presence of any CCD camera: IR emitting glasses
I think you missed the reference. If you haven't seen it before, it's hilarious.
Actually 6% or 5.6% or 5.56% or 5.555556% more bits
The whole idea of writing crap code, and "optimizing" it later, whether with automated tools or by handing it off to others, works very, very poorly in practice. Putting a little effort in, at the start, to architect services properly, and keeping an eye on the design through the coding process, pays off in spades later on.
I never suggested that it was a good idea to write crap code. I suggested that it's a good idea to have some developers focused on things that all developers need to be taking care of (e.g. a platform that supports universal tasks). In that way, you raise everyone's efficiency with a single core effort and the vast majority of the team can focus on implementing features that move the business forward.
Not to pick too nittily, but your assertion that a load balancer should just "go[es] to the most responsive server" is kind of simplistic. When I was working there, we had a failure mode where the most responsive server was one that had tripped over a subtle bug causing all subsequent requests to that instance of the service to almost immediately respond with an http 200 and empty content (it was a bug, after all, and it was compounded by this failure mode of returning a 200). Because we used weighted round-robin, we were able to diagnose that only some of the servers were behaving badly and could focus on reproducing the problem, finding the root cause and fixing it. The short-term mitigation was to bounce the ones in a bad state as they got into the bad state. This was at the cost of a poor user experience for 1/n of current traffic. In your proposed model, all traffic would have black-holed into this highly responsive server possibly making diagnosis and mitigation more difficult.
As far as having to abstract away the heavy lifting of service management into a dedicated layer, I'm in violent agreement with that architectural decision. Without providing service management as a service, you put the burden on everyone's shoulders to manage it themselves. I'd rather have 98% of the developers focused on application logic and a specialized 2% of the developers providing productivity improvements to the core platform.
While it might be more rewarding for some to re-blaze trails that have already been explored (and improvements do come out of parallel efforts) it's a much better business decision to put as much weight as possible behind moving the product forward and leave the task of lifting the efficiency of the platform to a dedicated team.