Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:And Fire qualifies for many definitions of Life (Score 5, Insightful) 401

For a definition of "life" to be meaningful, it needs to apply to bacteria, and not to fire, because the word has had meaning for a very long time, and it's meaning absolutely does not apply to fire.

I'm not trying to say that there aren't corner cases that are hard to define, but fire is not one of them, nor are bacteria.

Differentiating "just chemical reactions" from "life" is the purpose of said definition.

And yes, I am begging the question I suppose, but I will still stick by what I say.

Comment Re:STEM education is great but it's not everything (Score 4, Interesting) 655

Don't dismiss the value of "the lingo". It's painfully clear to me that one of the biggest problems is the lack of a shared meaning in words between two people or areas. When I'm in meetings where there are problems between people or groups, the key to solving them lies in discovering where they differ. And that takes careful listening.

For example, I might be in a meeting listening someone from dept A going on about unit testing their code, and someone else from dept B saying that they're not able to unit test dept A's code. So I get them both to ask each other "what do you mean by 'unit test'?" Turns out that nobody in the room knew jack about what an actual unit test was, and dept A was referring to the developer running the code in a debugger, and dept B was referring to passing the code to their testing team to run a bunch of functional tests. The start of the solution was to get them to use the right names for what each of them was doing. Once they both agreed on the terminology, we could address the real problem, which was that nobody knew shit about unit testing at all - they just thought they were doing it.

Comment Re:Personally (Score 3, Informative) 655

Our company's HR department posts the jobs, filters out the resumes, and passes only the ones forward that meet the job requirements we list as well as their fairly generic criteria. They also do some kind of pre-screening work, although I don't know what that is. That stops us from wasting our time weeding through a hundred applications from people who apply for any job, people who can't spell our company's name correctly, or those who claim "25 years Java experience." (Unless the resume was from James Gosling himself, that would be a hell of a thing to claim.) It's the managers and senior technical people in the departments who do the final interviews and make hiring recommendations. Over the last few years, I've only gotten a few "duds" from HR through this process - most were great candidates that I recommended we hire. This system works really well.

You might argue that we'll never hire the guy who is really smart but doesn't have a degree. And you'd be right - we won't even see his resume. It turns out that doesn't matter, because we still get a lot of very good people anyway, and I'm happy to work with any of them.

Comment Re:Cost is the key (Score 1) 237

One other point - this isn't primarily about increasing capacity. It's about replacing cars that have reached the end of their service life, and must be replaced anyway.

But yeah, they then have to do a bunch of cost benefit analysis. If the cost difference between a regular car and an articulated car is $3 million, and the car is expected to be in service for 50 years, and it costs $20,000/year more to maintain, and it can carry 5% more passengers, but the capacity is only used for six trips per day, and we assume fares are held in constant 2013 dollars, will the increased up front cost be covered by the increased revenue? (Show your work.)

Comment Re:Great article explaining what has changed (Score 3, Informative) 231

Yeah, that's great, except that in the real world apps like Gmail have to support all kinds of wacky browsers, including old ones that get kicked to "legacy" UIs, mobile browsers, browsers that are technically standards compliant but are much faster or slower than other browsers and so on.

I used to work on a server that vended browser specific code based on the user-agent (for a variety of reasons it had to be browser specific choices on the server side). It was a server that vended some self contained code that got embedded into lots of different web sites and properties. Anyway, the most painful browser to support was by far Internet Explorer. It blew my mind how badly they managed to screw this up. It's not that modern IE's are bad browsers, you see, they aren't really - after letting the web rot for years they finally reacted to their retreating market share by staffing up the IE team again, and nowadays it can render things nice and fast. The problem is their totally broken compatibility architecture.

Modern Internet Explorers are not a single browser. They're actually a wrapper around multiple different versions of the IE rendering engine, along with a horrific pile of heuristics, hacks and magical downloaded lists to try and select the right one. There's actually a giant flow chart that tries to describe what combination of bugs IE will try to emulate in any given situation, although that dates from 2010. Undoubtably it's now even more complicated. This is a total disaster. Firstly, IE isn't capable of always doing the right thing - a notorious example being the case where a top level document requests one kind of "document mode" (i.e. Trident version) and then an iframe requests a different kind, well, Trident can't recursively embed old versions of itself, so the iframe'd document just doesn't get the docmode it requested. If your code is run inside an iframe the only way to find out what docmode you're actually running in is to test it on the client side using JavaScript! If you then discover you have the wrong version of your JS loaded because IE lied to you, well, tough luck. Time to go reload it.

Combine this with trying to run code iframed into sites like Blogger where users are allowed to control their own toplevel HTML, and you can just forget about anything sane happening. But it gets even more confusing, because new versions of the rendering engine still have "quirks mode". You pretty quickly find yourself having to draw up giant matrices of how IE might behave in any given scenario.

What's worse, there are lots of different ways to ask IE for a specific mode. There are META tags, magic HTTP headers, DOCTYPE tags, and this Microsoft compatibility list which can override those in various situations, except that it works on a per domain basis and sites like google.com have tons of different apps hanging off different endpoints, some of which might no longer be really maintained, requiring a "flag day" where everyone co-ordinates to prepare for changes in the compatibility list. Oh yes, and users can and do modify their browser settings (as we see in this story), resulting in yet another column in the compatibility matrix.

Chrome, Firefox, Safari, Opera ... none of these browsers were such a nightmarish acid trip. Microsoft managed a seemingly impossible feat - dramatically improving the quality of their core rendering engine and yet STILL being the most horrible browser for web devs in existence! They snatched defeat from the claws of victory!

Comment Re:Cost is the key (Score 5, Interesting) 237

A big impediment to increasing capacity is the spacing required between trains for safety. Trains have to have adequate stopping distances between them, and rely on signals and blocks to prevent one train from running into the back of a stopped train. You can't just drop a few more trains onto the rails and expect them to fit in the gaps.

They can't simply add more cars to today's trains, because they can have only as many cars as they have platform space. It's possible these fully interconnected articulated cars would allow them to extend the train beyond the ends of the platform, as long as they only open the doors where it's safe, of course. But that would also increase the duration of stops, potentially reducing the number of trains.

Simply swapping cars for cars with more seats seems like the easiest and quickest approach to increasing capacity. But it's not much of an increase.

Comment Re:I want a Delorean (Score 1) 443

DeLoreans can go fast, it just takes a little while to get that fast -- the stock engine wasn't the greatest. Interesting trivia fact from Back to the Future -- the DeLorean speedometer actually only goes to 85 MPH, like all cars made back in the 80's (federal law). The 95 mph speedometer in the DeLorean in BTTF was custom made for the movie so that 88 mph wasn't "faster than the speedometer went."

Comment Re:missing the obvious (Score 1) 443

The other problem with electric cars is the range. 60 to 100 miles is fine for a commuter vehicle (for most commuters), but is no good for longer distances. So far, battery technology has not been able to create an all electric car with the range and recharge convenience of a gasoline, diesel, or natural gas vehicle. Find a way to solve this problem and get the cost down, then the electric car will be practical.

Comment Re:Office 365 (Score 4, Insightful) 337

Look at OwnCloud if you want to host your own stuff "in a cloud". But the sales pitch for Office 365 is that they do all the "icky computery" stuff, like backups and upgrades.

Of course the drawbacks of cloud are well known, too: you need to be online, you need to pay them monthly, and it can be read by anyone with a warrant (or not a warrant, if they're the NSA. )

Vendor lock-in changes, too. Sure, you can download an Office 365 document to import into Open Office. Today. And just because the TOS says you can today doesn't mean those terms can't be changed tomorrow.

There's a lot to dislike about cloud solutions. But they sure meet the needs of a lot of people - at least those who don't think about it too much.

Slashdot Top Deals

Machines certainly can solve problems, store information, correlate, and play games -- but not with pleasure. -- Leo Rosten

Working...