There is no learning curve in any of those switches so, it's not a valid comparison.
A more valid comparison might be DVORAK vs. QUERTY.
In principle, DVORAK is a more efficient, better choice, but I never seem to get around to investing the time to pick it up. Why? Because I already touch type QUERTY and so it's good enough for me on a day to day basis.
That, and in the likely event I had to go back to QUERTY for some task (someone else's machine), I know I'd be awfully clumsy with it.
Not to say I'd ever buy this, or even a new car, but if you do buy a new car (and it's not a 4 cylinder compact) you're probably blowing money at least that fast as you're rolling down the freeway.
In other words, if you can afford a TV that expensive, it just doesn't matter.
It used to be fun to see electric vehicles tangling successfully on the performance end of the spectrum. Now, I think the golf cart myth is pretty well shattered and there's only so much market for toys.
So, how about a 4 seater that's priced reasonably (under 30K), can tangle on the freeway, and has enough range to not make you worry about having to fit in a recharge during a busy day of commuting, picking up kids, running errands, etc...
Whoever does this first makes billions. People are very practical and will favor electric cars when they work in their lifestyle simply due to the fact that they will feel newer longer, and cost so little to maintain.
You and I have very different opinions about the way the process should work, doubtless based on very different experiences. The opinions you expressed matched those of managers I've met with little experience in software. I mentally slotted you in that group, and I was wrong. Please don't take it personally.
My experience has primarily been with business web applications, which is nothing special, but a good way to pay bills, and an endeavor that a large fraction (the majority I'm guessing) of developers are involved in. I do have strong opinions based on that experience. That doesn't make me a blowhard.
I'll admit to not understanding the majority of your last post. I don't want to start another round till I understand it better.
Let's take this off slashdot... I doubt we'll agree, but I do think we might have another couple interesting rounds of discussion and maybe we'll both learn something. byogman (at) gmail (dot) com.
I accept that aircraft, the space shuttle, etc.. are insanely complicated, and aircraft contains software as well as hardware. You should accept that operating systems, for instance are extremely complicated. We have no real way of measuring respective complexity. It doesn't matter much which is more complicated. I wouldn't presume to tell Boeing how to make a plane. You shouldn't presume to tell me how to make software.
I have had some good experiences, some bad. I'm not a cynic, or even a grizzled veteran. I am just someone that tries to learn something from each experience.
Every experience I've had tells me the following things:
1. Problem solving skills matter, experience with specific APIs doesn't. Experience with problem areas does help, but not as much as good problem solving skills in general. People with really good problem solving skills are rare and invaluable. 2. Good code, good in code comments, a good wiki, and good tests matter. Specs, diagrams, and long documents don't matter. 3. The more responsibility is distributed horozontally (peers working on semi-independant subsystems) rather than vertically (architects handing off their castle in the sky for someone else to build), the less communication overhead, the less misunderstanding, the better the team atmosphere, and the better things work. 4. The fewer layers of communication overhead there are between the users who have needs of a system and the developers who build features to meet there needs, the better the resulting system will meet the users needs and not become a tangled mess of inflexible, nonesensical requirements.
Returning to planes, let's imagine someone told you in the course of a few weeks that your plane needs to hold 5X as much cargo and be able to take off and land with half the runway, and in icy conditions, and by the way you have to reduce the engine noise by 20%, make the cockpit intrusion-proof against high explosives, and build in a ground based override in case the plane gets hijacked anyways, and build in a plane based override in case the ground systems get hijacked (and no, we don't see that the requirements are contradictory, sort it out!). How many planes would be falling out of the sky now?
Well of course, boeing wouldn't try to do that. We in software are asked to every day because the consequences of our planes falling out of the sky just isn't nearly as bad 99.99% of the time. We still should push back more than we do, but have some respect... we're not chimps at typewriters trying to save our jobs, we're skilled professionals tackling very hard problems and more angry about everything broken in the process (mostly imposed by those with no ground level experience trying to impose their vision) than you will ever be.
You clearly don't do this for a living. There all always trade-offs, corner cases, performance considerations, and other things that can be important to the architecture of the system, and are impossible to get right without being familiar with the details. Once you are there looking at the details, it almost always takes less time to do it yourself than it takes to explain it in sufficient detail, even to someone on your level. We don't need more low skill level developers, we need more high skill level developers.
Traditionally, architects write code that's used by a lot of other code, or whose side state-full behavior is important to a lot of other code. People with lesser titles do work that doesn't impact the system as widely. But, at the end of the day it's all code, and programming, development, and architecting are less descriptive of different kinds of work than they are of the esteem that work is held in. You clearly esteem education, which is fine, but I'll tell you it correlates only marginally with the ability to actually design a good system.
People complain about software all the time, and fantasize about silver bullets, but the reason software sucks is that its design is way, way more complex than anything that's industrialized. The ability to code in such a way that promotes reuse is one of the most important attributes a developer can have. Still, reuse can only reduce a problem so much, and in the end software is complex is because you, the business, ask us for complexity. Cookie cutter solutions don't satisfy... see the failure of every touted 4GL. Software in particular will stay complicated as the cost of change in software is lower than anything where you have a lot of physical product to scrap. That's also why people will complain about software more than anything else, because in the end it's as much a problem of getting people to agree as it is to build a product.
Bad analogy because you can't just go out and buy your IT infrastructure, plug it in, and have it work.
I own my home, but I didn't build it and it wouldn't have worked well if I tried. I could subcontract the building out, but even then I'd need to hire an architect to make plans, and I know I'd spend a lot of time coordinating the subcontractors I'd rather spend doing other things.
Faced with that, I'd be very tempted to just rent a place I like.
Either way, you have continuing costs, so the non-payment scenario is bogus.
Now, my analogy fails because when moving, you don't have to contend with the owner chaining your belongings to the floor. That would be my concern... I want a hard fast guarantee that I have access to my data at all times built into any kind of IT service arrangement.
If I could get that source of agreement, I'd be somewhat tempted.
There are two kinds of feedback, feedback on their answers to specific questions, and feedback about them as a candidate.
You should never give feedback about them as an overall candidate, you are strangers and anything talking about THEM is going to be taken as judgement. Besides, it doesn't serve any purpose... nothing changes who they are.
As for answers to specific questions, feedback is a waste of breath unless they miss the mark only narrowly, and you want them to have a particular point straight so you can ask some other questions. In general though, it's better if most of your questions don't depend on answers to earlier questions.
Back in the late 90s, I used to recommend browsing downward to see if there was anything in the hierchical categorization of web content Yahoo set up as a complement to the many, but often irrelevant results people got back from AltaVista.
Fast forward to days of Google and Wikipedia and you have infinitely better "dumb" search, and an equally easy to use, generally decently accurate, and well contained treatment of a dizzying array of topics.
So, what's needed to fill the "search for information" gap? I doubt it's an attempt at hierarchical categorization, people don't try and absorb a whole lot of related content at once, they want an answer, and the navigation was a pain even back then. So then, just using people to try and make the dumb search results better? Well yes, but Google is continuously working to fill that gap itself. Nobody really comes close that I've seen. Even back in the late 90s those yahoo directories got stale quickly both in terms of dead links, and missing good newer content. Now, you can automatically test for and prune dead links, but results WILL get dated quickly.
Humans are SLOW, especially when you consider that their number is limited to those you hire if you want to avoid opening yourself up to the kind of spamming google has to contend with, which they're putting forward as a key differentiator in what they're trying. The web is several orders of magnitude bigger now than it was then, and it didn't work then, so what exactly makes Jimbo think it will work now?
Still, you should ask, what's a reasonable third factor? One important, but very difficult to measure factor in health and longevity, is how much a person stresses things. The correlation given here between light to moderate drinking and longevity seems to me to be a natural expression of this. In the absence of specifics about what's particularly healthy about metabolizing ethanol, that's what I'm chocking this up to.
In detail: For many who strictly avoid alchohol it's a dogma, and whether it's a particularly hard dogma for that person to follow or not, it suggests to me that person is more likely to be dogmatic in other ways and at least some aspects of their dogmatism will create stress when they meet with reality. Drinking heavily suggests an avoidance pattern to an underlying stressor, so they rarely or never clear the underlying stressors, and in spite of the drinking, live a stress filled life. Plus, it kills your liver.
The reason for the difference between beer/wine and hard licquor? People will drink beer/wine with meals, not so much with hard licquor so even with equivalent consumption the licquor drinker's blood alchohol level spikes higher and does more underlying damage. Plus, it seems from my personal experience that licquor hits you quicker. That speed would make it even more inviting for avoidance drinkers.
So, my message? I doubt alchohol is health food, but as long as you're not drinking a lot at once, or drinking to avoid something (be honest with yourself here!), I wouldn't worry about it.
The flip side is that very often you want a class to do something very similar to a final class String comes to mind for regular expressions and DNA, but there are many possibilities. I'd say there are really more for collections I'd say than for String, but whenever you see static util classes popping up on the same class for different reasons it's clear that isomething is broken in OO land.
You can create a wrapper and manually delegate everything, but I think this happens frequently and brainlessly enough that there should be in-built language support for delegating a particular interface to a member of the class. Then just override what, if anything, it makes sense to override.
Anyways, my 2c. I have a lot of gripes with Java.
BTW: Referring back to the String example, there's another problem. The interfaces don't come anywhere close to covering the members of String. It's not hard to solve this problem... just create the new interface(s) and declare that String implements it/them. By not creating standard covering interfaces you're not only encouraging, you're more or less demanding a lot of concrete instances of String, when what you really mean is something String-like in some way.
While good for a gag gift, I don't think this is useful for broadening horizons... way too painful.
Here's a better idea:
Given the books I've liked, and the books I've disliked, find me a book that my profile tells you the least (widest confidence interval on expected rating) about whether I'd like it or not.
This would have the effect of encouraging genre hopping, and encouraging the reading of fairly evenly split love it or hate it books, which are often interesting at least in concept. Sounds a lot better than reading 10 books on topic X.
I might even want to see some of this behavior weighted into the normal recommendation system, and if you do want to keep the old recommendations around change their listing heading to "Similar books" rather than "Recommended".
So, I don't know whether electrical overload, or water infiltration, or physical shocks, or bad batteries are really the major source of failures... I don't really buy these things because at the end of the day I want to unplug. Still, it seems like it should be pretty easy/cheap to design for protection against all of the above, though, especially if you go solid state on storage.
And what makes this not waste energy by pumping it in all directions, or not waste energy when there's nothing around to charge? Not saying I don't believe they have something as cool as they say, I just want to know how it works.
My starting point is just Tesla and magnetic flux.
A couple toroids of copper wire and a couple squigly blue lines don't give me anything more. Your sound wave analogy is pretty, but doesn't really improve my understanding.
Does anyone really know how this is supposed to work?
Let's take an ordinary 15 or 17 inch laptop, find a way to pack an identically sized lcd with it securely.
Finally use a convenient connector to that second LCD (I'm not up on what would be good here... I'm looking for something that I don't have to screw in and I'm guessing it does exist. Bonus points if the same connector can provide power to the second LCD, too).
You can either take the additional LCD or not, depending on your desired setup, and whether you'll have the juice to run two LCDs. Should be cheaper than this, and more usable for most applications.
Your last question deserves an answer: Only a very small fraction of the general population has inordinately high muscle mass. You may be an exception, but almost all people who score overweight have more fat than is healthy.
BMI scoring is broad ranges which accounts for most natural variation in bone structure and density and muscle mass. 25(borderline overweight)/18.5(borderline underweight) = 1.35, 35% of body weight as a fudge factor. Unless you're a competitive bodybuilder, does that not seem like enough??
It's already developed, has a pretty good record of success, and is cheap (comparatively).
Additionally, it doesn't subject its payload to 2000Gs, doesn't send anything ripping through the thick parts of the atmosphere at mach 23, and doesn't create an easy target for sabotage.
Launching from an asteroid or maybe a very small moon this could make sense, but intuitively this doesn't seem like a good fit for launches from earth.
1/3 of income to support their vehicle(s)? People are often pretty crazy when it comes to consumerism, but that I don't believe.
You're undoubtably looking at the cost of ownership for new cars compared to income.
New cars are expensive because of depreciation, insurance, and taxes being much higher. However, most cars on the road are not new or even close to it.
It's hard to find reliable stats on how old the "average" car is, and "average" itself begs the iquestion of mean median or mode. Likewise, it's hard to find reliable stats on how much it takes to keep a car going, especially past the first few years of life, and there's a lot of variability in that number.
So, I won't throw unsourced numbers at you, but here's some basic reasoning based on some facts that are, hopefully, obvious enough to be acceptable to you.
The largest cost of new car ownership is depreciation, hands down. By the time a car is a few years old, the amount it's depreciating per year in absolute dollar amounts is very, very small in comparison. Repairs and maintenance will cost more, but otherwise costs are the same or less.
Few owners would put up with thousands and thousands in repairs per year, just because of the hassle being too great. Yet somehow, the cars you're seeing have stayed on the road year after year, presumably in most cases it doesn't take thousands and thousands a year to keep them going.
Now, drive around (you'll get a more representative sample than you would taking the bus). Take a survey of how old the cars you see actually are. Unless you're driving around and unusually well to-do neighborhood, I'll wager that most are from the 90s, not the 2000s, and you'll see a surprising number of cars that people are still using from early 90s and holdovers from the late 80s. These people are certainly not spending 1/3 of their income their cars now, and many will have bought the car used in the first place.
If you hear an outrageous claim, it is either A: True, in spite of whatever it is that makes it outrageous B: False, positioned as truth by someone with an agenda
Disclaimer: I subscribe to the same sort of service, except through blockbuster... maybe Netflix does have this feature.
My wife and I share a queue... I imagine many, many of these queues are shared.
We have very, very different tastes in movies.
Instead of getting recommendations that suit us both (which is next to impossible), the recommendations just get very, very confused.
If I could just keep my and her recommendations from tangling, we would both have an easier time.
Like suffering through the crowds, the overal filthiness, and the inhumanly slow checkout lines at Walmart. No thanks.
Target is a reasonable compromise in my experience.
It's important to be able to look at algorithm, consider the inputs, consider the corner cases on the inputs and in intermediate values/data structures, and find what doesn't degrade nicely enough, or is broken outright.
However, having this skill does not make you a genius, just competent to puzzle out technical problems once you know the cast of characters in that problem domain/area of code.
By the tone of your post I'd guess that you generally look down on most of your peers. By the outcome of the interview I'd guess that it shows. It's really that simple.
Sincerely,
Ben Yogman
Recovering Asshat
Somehow, I don't think this type of captcha presents any kind of barrier to a.60/hr price point.
Actually, the price on this would be lower... don't need to squint, no need to know the english alphabet even, and the captcha solver can focus attention on the hot chick.
I wonder when this gets plugged into tracking system with etc estimates. I had a manager who tried to work pretty close to blindly from those numbers (which is of course completely bogus because your pool of developers have different skills and experience and etcs don't carry over when you switch horses midstream or when you force someone to concentrate on something else for weeks and then come back to the original task).
At least this would work from numbers that aren't stale (week-old excel reports on a 2-3 week release cycle) and would have the ability to evaluate all the pieces against deadlines simultaneously and calculate fits reasonably rather than just looking at pieces individually and seeing if, independently, they fit. It would also be much better at figuring out risk as it could tally variability against estimates and start padding to acceptable risk levels.
I think there are a lot of planning and managing roles in all fields that just need a little better definition and become easy candidates for automation, at least in significant part.
Slashdot Mirror
There is no learning curve in any of those switches so, it's not a valid comparison.
A more valid comparison might be DVORAK vs. QUERTY.
In principle, DVORAK is a more efficient, better choice, but I never seem to get around to investing the time to pick it up.
Why? Because I already touch type QUERTY and so it's good enough for me on a day to day basis.
That, and in the likely event I had to go back to QUERTY for some task (someone else's machine), I know I'd be awfully clumsy with it.
Not to say I'd ever buy this, or even a new car, but if you do buy a new car (and it's not a 4 cylinder compact) you're probably blowing money at least that fast as you're rolling down the freeway.
In other words, if you can afford a TV that expensive, it just doesn't matter.
It used to be fun to see electric vehicles tangling successfully on the performance end of the spectrum.
Now, I think the golf cart myth is pretty well shattered and there's only so much market for toys.
So, how about a 4 seater that's priced reasonably (under 30K), can tangle on the freeway, and has enough range to not make you worry about having to fit in a recharge during a busy day of commuting, picking up kids, running errands, etc...
Whoever does this first makes billions. People are very practical and will favor electric cars when they work in their lifestyle simply due to the fact that they will feel newer longer, and cost so little to maintain.
You and I have very different opinions about the way the process should work, doubtless based on very different experiences. The opinions you expressed matched those of managers I've met with little experience in software. I mentally slotted you in that group, and I was wrong. Please don't take it personally.
My experience has primarily been with business web applications, which is nothing special, but a good way to pay bills, and an endeavor that a large fraction (the majority I'm guessing) of developers are involved in. I do have strong opinions based on that experience. That doesn't make me a blowhard.
I'll admit to not understanding the majority of your last post. I don't want to start another round till I understand it better.
Let's take this off slashdot... I doubt we'll agree, but I do think we might have another couple interesting rounds of discussion and maybe we'll both learn something. byogman (at) gmail (dot) com.
I accept that aircraft, the space shuttle, etc.. are insanely complicated, and aircraft contains software as well as hardware. You should accept that operating systems, for instance are extremely complicated. We have no real way of measuring respective complexity. It doesn't matter much which is more complicated. I wouldn't presume to tell Boeing how to make a plane. You shouldn't presume to tell me how to make software.
I have had some good experiences, some bad. I'm not a cynic, or even a grizzled veteran. I am just someone that tries to learn something from each experience.
Every experience I've had tells me the following things:
1. Problem solving skills matter, experience with specific APIs doesn't. Experience with problem areas does help, but not as much as good problem solving skills in general. People with really good problem solving skills are rare and invaluable.
2. Good code, good in code comments, a good wiki, and good tests matter. Specs, diagrams, and long documents don't matter.
3. The more responsibility is distributed horozontally (peers working on semi-independant subsystems) rather than vertically (architects handing off their castle in the sky for someone else to build), the less communication overhead, the less misunderstanding, the better the team atmosphere, and the better things work.
4. The fewer layers of communication overhead there are between the users who have needs of a system and the developers who build features to meet there needs, the better the resulting system will meet the users needs and not become a tangled mess of inflexible, nonesensical requirements.
Returning to planes, let's imagine someone told you in the course of a few weeks that your plane needs to hold 5X as much cargo and be able to take off and land with half the runway, and in icy conditions, and by the way you have to reduce the engine noise by 20%, make the cockpit intrusion-proof against high explosives, and build in a ground based override in case the plane gets hijacked anyways, and build in a plane based override in case the ground systems get hijacked (and no, we don't see that the requirements are contradictory, sort it out!). How many planes would be falling out of the sky now?
Well of course, boeing wouldn't try to do that. We in software are asked to every day because the consequences of our planes falling out of the sky just isn't nearly as bad 99.99% of the time. We still should push back more than we do, but have some respect... we're not chimps at typewriters trying to save our jobs, we're skilled professionals tackling very hard problems and more angry about everything broken in the process (mostly imposed by those with no ground level experience trying to impose their vision) than you will ever be.
You clearly don't do this for a living. There all always trade-offs, corner cases, performance considerations, and other things that can be important to the architecture of the system, and are impossible to get right without being familiar with the details. Once you are there looking at the details, it almost always takes less time to do it yourself than it takes to explain it in sufficient detail, even to someone on your level. We don't need more low skill level developers, we need more high skill level developers.
Traditionally, architects write code that's used by a lot of other code, or whose side state-full behavior is important to a lot of other code. People with lesser titles do work that doesn't impact the system as widely. But, at the end of the day it's all code, and programming, development, and architecting are less descriptive of different kinds of work than they are of the esteem that work is held in. You clearly esteem education, which is fine, but I'll tell you it correlates only marginally with the ability to actually design a good system.
People complain about software all the time, and fantasize about silver bullets, but the reason software sucks is that its design is way, way more complex than anything that's industrialized. The ability to code in such a way that promotes reuse is one of the most important attributes a developer can have. Still, reuse can only reduce a problem so much, and in the end software is complex is because you, the business, ask us for complexity. Cookie cutter solutions don't satisfy... see the failure of every touted 4GL. Software in particular will stay complicated as the cost of change in software is lower than anything where you have a lot of physical product to scrap. That's also why people will complain about software more than anything else, because in the end it's as much a problem of getting people to agree as it is to build a product.
Bad analogy because you can't just go out and buy your IT infrastructure, plug it in, and have it work.
I own my home, but I didn't build it and it wouldn't have worked well if I tried.
I could subcontract the building out, but even then I'd need to hire an architect to make plans, and I know I'd spend a lot of time coordinating the subcontractors I'd rather spend doing other things.
Faced with that, I'd be very tempted to just rent a place I like.
Either way, you have continuing costs, so the non-payment scenario is bogus.
Now, my analogy fails because when moving, you don't have to contend with the owner chaining your belongings to the floor. That would be my concern... I want a hard fast guarantee that I have access to my data at all times built into any kind of IT service arrangement.
If I could get that source of agreement, I'd be somewhat tempted.
There are two kinds of feedback, feedback on their answers to specific questions, and feedback about them as a candidate.
You should never give feedback about them as an overall candidate, you are strangers and anything talking about THEM is going to be taken as judgement. Besides, it doesn't serve any purpose... nothing changes who they are.
As for answers to specific questions, feedback is a waste of breath unless they miss the mark only narrowly, and you want them to have a particular point straight so you can ask some other questions. In general though, it's better if most of your questions don't depend on answers to earlier questions.
Back in the late 90s, I used to recommend browsing downward to see if there was anything in the hierchical categorization of web content Yahoo set up as a complement to the many, but often irrelevant results people got back from AltaVista.
Fast forward to days of Google and Wikipedia and you have infinitely better "dumb" search, and an equally easy to use, generally decently accurate, and well contained treatment of a dizzying array of topics.
So, what's needed to fill the "search for information" gap? I doubt it's an attempt at hierarchical categorization, people don't try and absorb a whole lot of related content at once, they want an answer, and the navigation was a pain even back then. So then, just using people to try and make the dumb search results better? Well yes, but Google is continuously working to fill that gap itself. Nobody really comes close that I've seen. Even back in the late 90s those yahoo directories got stale quickly both in terms of dead links, and missing good newer content. Now, you can automatically test for and prune dead links, but results WILL get dated quickly.
Humans are SLOW, especially when you consider that their number is limited to those you hire if you want to avoid opening yourself up to the kind of spamming google has to contend with, which they're putting forward as a key differentiator in what they're trying. The web is several orders of magnitude bigger now than it was then, and it didn't work then, so what exactly makes Jimbo think it will work now?
Still, you should ask, what's a reasonable third factor? One important, but very difficult to measure factor in health and longevity, is how much a person stresses things. The correlation given here between light to moderate drinking and longevity seems to me to be a natural expression of this. In the absence of specifics about what's particularly healthy about metabolizing ethanol, that's what I'm chocking this up to.
In detail:
For many who strictly avoid alchohol it's a dogma, and whether it's a particularly hard dogma for that person to follow or not, it suggests to me that person is more likely to be dogmatic in other ways and at least some aspects of their dogmatism will create stress when they meet with reality. Drinking heavily suggests an avoidance pattern to an underlying stressor, so they rarely or never clear the underlying stressors, and in spite of the drinking, live a stress filled life. Plus, it kills your liver.
The reason for the difference between beer/wine and hard licquor? People will drink beer/wine with meals, not so much with hard licquor so even with equivalent consumption the licquor drinker's blood alchohol level spikes higher and does more underlying damage. Plus, it seems from my personal experience that licquor hits you quicker. That speed would make it even more inviting for avoidance drinkers.
So, my message?
I doubt alchohol is health food, but as long as you're not drinking a lot at once, or drinking to avoid something (be honest with yourself here!), I wouldn't worry about it.
All this is very true.
The flip side is that very often you want a class to do something very similar to a final class String comes to mind for regular expressions and DNA, but there are many possibilities. I'd say there are really more for collections I'd say than for String, but whenever you see static util classes popping up on the same class for different reasons it's clear that isomething is broken in OO land.
You can create a wrapper and manually delegate everything, but I think this happens frequently and brainlessly enough that there should be in-built language support for delegating a particular interface to a member of the class. Then just override what, if anything, it makes sense to override.
Anyways, my 2c.
I have a lot of gripes with Java.
BTW: Referring back to the String example, there's another problem. The interfaces don't come anywhere close to covering the members of String. It's not hard to solve this problem... just create the new interface(s) and declare that String implements it/them. By not creating standard covering interfaces you're not only encouraging, you're more or less demanding a lot of concrete instances of String, when what you really mean is something String-like in some way.
While good for a gag gift, I don't think this is useful for broadening horizons... way too painful.
Here's a better idea:
Given the books I've liked, and the books I've disliked, find me a book that my profile tells you the least (widest confidence interval on expected rating) about whether I'd like it or not.
This would have the effect of encouraging genre hopping, and encouraging the reading of fairly evenly split love it or hate it books, which are often interesting at least in concept. Sounds a lot better than reading 10 books on topic X.
I might even want to see some of this behavior weighted into the normal recommendation system, and if you do want to keep the old recommendations around change their listing heading to "Similar books" rather than "Recommended".
The direct analogy is to electrical fuses.
So, I don't know whether electrical overload, or water infiltration, or physical shocks, or bad batteries are really the major source of failures... I don't really buy these things because at the end of the day I want to unplug. Still, it seems like it should be pretty easy/cheap to design for protection against all of the above, though, especially if you go solid state on storage.
And what makes this not waste energy by pumping it in all directions, or not waste energy when there's nothing around to charge? Not saying I don't believe they have something as cool as they say, I just want to know how it works.
My starting point is just Tesla and magnetic flux.
A couple toroids of copper wire and a couple squigly blue lines don't give me anything more.
Your sound wave analogy is pretty, but doesn't really improve my understanding.
Does anyone really know how this is supposed to work?
It seems much more likely to me, since we all
1: Don't have clearance
2: Haven't been given access
3: Don't need to know anyway
that we just aren't being told what the security mechanisms are in place or what their technical underpinnings are.
Nothing to see here folks, move along!
slashdot.org is:
News for nerds. Stuff that matters.
Notice, these are two separate sentences.
Let's take an ordinary 15 or 17 inch laptop, find a way to pack an identically sized lcd with it securely.
Finally use a convenient connector to that second LCD (I'm not up on what would be good here... I'm looking for something that I don't have to screw in and I'm guessing it does exist. Bonus points if the same connector can provide power to the second LCD, too).
You can either take the additional LCD or not, depending on your desired setup, and whether you'll have the juice to run two LCDs. Should be cheaper than this, and more usable for most applications.
Your last question deserves an answer:
Only a very small fraction of the general population has inordinately high muscle mass. You may be an exception, but almost all people who score overweight have more fat than is healthy.
BMI scoring is broad ranges which accounts for most natural variation in bone structure and density and muscle mass. 25(borderline overweight)/18.5(borderline underweight) = 1.35, 35% of body weight as a fudge factor. Unless you're a competitive bodybuilder, does that not seem like enough??
It's already developed, has a pretty good record of success, and is cheap (comparatively).
Additionally, it doesn't subject its payload to 2000Gs, doesn't send anything ripping through the thick parts of the atmosphere at mach 23, and doesn't create an easy target for sabotage.
Launching from an asteroid or maybe a very small moon this could make sense, but intuitively this doesn't seem like a good fit for launches from earth.
1/3 of income to support their vehicle(s)?
People are often pretty crazy when it comes to consumerism, but that I don't believe.
You're undoubtably looking at the cost of ownership for new cars compared to income.
New cars are expensive because of depreciation, insurance, and taxes being much higher.
However, most cars on the road are not new or even close to it.
It's hard to find reliable stats on how old the "average" car is, and "average" itself begs the iquestion of mean median or mode. Likewise, it's hard to find reliable stats on how much it takes to keep a car going, especially past the first few years of life, and there's a lot of variability in that number.
So, I won't throw unsourced numbers at you, but here's some basic reasoning based on some facts that are, hopefully, obvious enough to be acceptable to you.
The largest cost of new car ownership is depreciation, hands down. By the time a car is a few years old, the amount it's depreciating per year in absolute dollar amounts is very, very small in comparison. Repairs and maintenance will cost more, but otherwise costs are the same or less.
Few owners would put up with thousands and thousands in repairs per year, just because of the hassle being too great. Yet somehow, the cars you're seeing have stayed on the road year after year, presumably in most cases it doesn't take thousands and thousands a year to keep them going.
Now, drive around (you'll get a more representative sample than you would taking the bus). Take a survey of how old the cars you see actually are. Unless you're driving around and unusually well to-do neighborhood, I'll wager that most are from the 90s, not the 2000s, and you'll see a surprising number of cars that people are still using from early 90s and holdovers from the late 80s. These people are certainly not spending 1/3 of their income their cars now, and many will have bought the car used in the first place.
If you hear an outrageous claim, it is either
A: True, in spite of whatever it is that makes it outrageous
B: False, positioned as truth by someone with an agenda
Hint: B is far more likely
Disclaimer: I subscribe to the same sort of service, except through blockbuster... maybe Netflix does have this feature. My wife and I share a queue... I imagine many, many of these queues are shared. We have very, very different tastes in movies. Instead of getting recommendations that suit us both (which is next to impossible), the recommendations just get very, very confused. If I could just keep my and her recommendations from tangling, we would both have an easier time.
Like suffering through the crowds, the overal filthiness, and the inhumanly slow checkout lines at Walmart. No thanks. Target is a reasonable compromise in my experience.
It's important to be able to look at algorithm, consider the inputs, consider the corner cases on the inputs and in intermediate values/data structures, and find what doesn't degrade nicely enough, or is broken outright. However, having this skill does not make you a genius, just competent to puzzle out technical problems once you know the cast of characters in that problem domain/area of code. By the tone of your post I'd guess that you generally look down on most of your peers. By the outcome of the interview I'd guess that it shows. It's really that simple. Sincerely, Ben Yogman Recovering Asshat
Somehow, I don't think this type of captcha presents any kind of barrier to a .60/hr price point.
Actually, the price on this would be lower... don't need to squint, no need to know the english alphabet even, and the captcha solver can focus attention on the hot chick.
I wonder when this gets plugged into tracking system with etc estimates. I had a manager who tried to work pretty close to blindly from those numbers (which is of course completely bogus because your pool of developers have different skills and experience and etcs don't carry over when you switch horses midstream or when you force someone to concentrate on something else for weeks and then come back to the original task).
At least this would work from numbers that aren't stale (week-old excel reports on a 2-3 week release cycle) and would have the ability to evaluate all the pieces against deadlines simultaneously and calculate fits reasonably rather than just looking at pieces individually and seeing if, independently, they fit. It would also be much better at figuring out risk as it could tally variability against estimates and start padding to acceptable risk levels.
I think there are a lot of planning and managing roles in all fields that just need a little better definition and become easy candidates for automation, at least in significant part.