Insurance and to some extent maintenance is a sunk cost. You pay it whether you're driving the car ten miles per month or a thousand. Thus, the only people for whom that enters into the equation are the one who conclude that they can reduce their number of cars by one or more.
Actually, that's pretty easy. About 10% of the asteroids in the belt between here and Mars are mostly metal. The materials are already in space. The problem is not a lack of material or a lack of energy. The problem is a lack of motivation.
As I posted on Facebook the other day, when animals find their local habitat too constrained, they venture out into the wider world to seek a better one. So, too, must we as a species venture out among the stars if we are to thrive.
All the naysayers saying that the Earth can't handle the population don't get it. If we don't face evolutionary pressure to move out of our proverbial parents' house, we're never going to grow up as a species. It is precisely that adversity—that struggle to do more with limited resources—that is the force that drives the human race forward, and as such, it is no more something to be feared than life itself.
They'll be able to buy more stuff with less credit, but they won't be better off at the end, specifically because the investments into actual production capacity would have been cut dramatically.
What investments in production capacity? The U.S. hasn't done that in any significant way for as long as I've been alive. It just outsources the labor to some other country where the cost of labor is cheaper.
Don't get me wrong, I think it would be great for the U.S. to invest in production capacity. I'm just not convinced that leaving the money in the hands of the same rich people who have repeatedly failed to invest in that capacity will miraculously cause that to happen. The extremely wealthy do not create jobs. The people who create jobs are the middle class workers who start small businesses.
If you want production capacity, take the money from the rich and give it to the middle class. Some of those people will just buy consumable goods, but the ones who are not barely getting by will look for ways to invest that in things that can make money, including the production capacity you so crave.
And sure, in the end, maybe you've created a new top 1%, but at least some part of that new top 1% will be made up of people who aren't squeezing that last cent out of the market by outsourcing everything to China.
You do realize if you try that, you simply change the names of the 1% as they take over the transfer...
Although you are technically correct (the best kind of correct), that's a rather useless way of viewing money. In the U.S., the top 20% have about 85% of the accumulated wealth, and the top 5% have almost 60%, which makes it a remarkably lopsided distribution, with the vast majority of people living below the mean.
What this means is that if you repeatedly cut the top 1% down to the mean and distribute it among everyone else, it doesn't take long before you have dramatically increased the overall standard of living.
The bigger problem I have with your post is the assumption that the rich have predominantly earned their money. There's earned income, and there's unearned income (capital gains, interest, etc.). The vast majority of working class income falls into the first category. The vast majority of upper class income falls into the latter category. So any tax scheme that does not tax the upper class more than the working class is unfair because it takes away money that the working class have earned to allow the rich to keep more money that they haven't earned.
After finding a brand of shoes I like, I buy them in bulk. I'm just reaching the end of the stack of shoe boxes I bought four or five years ago. It's almost time to buy shoes again.
As for clothing, I have a closet full of short-sleeve shirts, and a closet full of long-sleeve shirts. Clothes last a long time if you wear them only once per month. Also, my parents often give me a shirt or two for Christmas, which further reduces the need to actually shop for clothes. And I buy white socks in bulk every few years so that they all match (which saves a lot of time while folding them).
So basically, the pattern is that I tend to buy a crapload of what I need when I realize that I need it, and then I don't buy any of that type of item again for months or years. I buy bar soap about once a year. I buy bottles of hand soap about once a year. I buy toothpaste about once a year. And so on. So it's probably not that I buy fewer total clothes than you, so much as that I buy more clothes less often.
You can make high quality products with Chinese manufacturers, but you have to be very selective about which manufacturers you'll work with, and you have to pull random inspections to ensure that they are actually doing the QA testing they claim to be doing. Otherwise they'll send you half junk.
A lot of it also depends on the design work that went into it. If you've done the board layout and testing yourself, repeatedly ordering new test runs until you get a layout with perfect or near-perfect yield, you'll do a lot better than if you order a test run, have a 50% failure rate, and say, "It's okay. When people return it, we'll just send them a new one and toss the old one out."
The main reason to go with China is that it's just about the only place I've found where companies will even talk to you about small-run manufacturing. They've become experts at retooling a factory floor very rapidly for new products, which means that whether your production run is a thousand units or a million units, they can easily accommodate you. Most companies in the U.S., not so much. Thus, if you're a small business that's just starting out, unless you managed to secure the rather sizable funding to build your own manufacturing plant, outsourcing to China is usually the most feasible way to see your design actually turn into a physical product.
colleague who has a facebook account but has never posted anything, not a photo, not even information in the profile got a recommendation from Facebook to add as a friend someone who is in her cancer survivor's group. The absolutely only bit of information about her that she's been able to find on Facebook is a photograph from a different friend's profile in which she appears but is not named in the photo's info. As I said, she has never posted anything about herself and the person who was recommended to her is not the facebook friend of a facebook friend.
Nah. It's a lot dumber than that. Your colleague probably has several friends who have several friends, and if you walk through a few degrees of separation, there are probably at least two paths that connect her to the suggested person.
I mostly see people I've never met as a result of those algorithms, but every once in a while, it lists somebody who I know peripherally.
Why is this bad? I'd rather see ads for things I like and might consider buying than scattershot ads for shit I'd never use.
If only it were actually that good. Every time I see an ad for a company whose products compete with products made by my employer (that I thus almost certainly wouldn't even consider buying), I conclude that they must not be doing much more than a trivial keyword search (and they know who my employer is, so that's just a Facepalm right there).
And as that satellite fell out of orbit a couple of weeks ago, I was summarizing a bunch of random Twitter feeds and news reports on my Facebook feed. As a result, I was seeing all sorts of bizarre ads related to all the cities that I mentioned, like "Travel to Hawaii", followed by "Travel to Ontario".... Completely and totally out to lunch.
Of course, if you asked me what kinds of products I buy more than once in any given year, you'd get the following list:
Frozen food
Restaurant food
Milk
Hot cocoa mix
Cashews
Chocolate
Clothing (some years)
Shoes (some years)
Books
Movies
Spare hard drives
Flash drives (some years)
DV tapes (some years)
Camera-related gear
Audio-related gear
Gasoline
Copy paper
And that would be the end of the list. If you're advertising anything that's not on that list, it's noise. Given that (with the exception of movies) almost none of the products on the list are regularly advertised on pretty much any website, web advertisements rarely have any real impact on my buying habits. Then again, as the sort of person who will spend three hours browsing Amazon reviews before buying a blender, and the sort of person who mostly buys twentieth-run movies from the $5.99 bin instead of new releases, I'm not sure they'd affect me much even if they covered the products I buy regularly.
The kind of advertisement that does affect me, if you can call it that, is word-of-mouth advertisement. Specifically, if you make a good product, and people give it consistently good reviews, I'm more likely to buy your product. If you make a s**tty product that falls apart in six months, I'm more likely to call up a manufacturer in China and go into business against you (which isn't very likely to happen at all, but is still a heck of a lot more likely than me buying your junk product).
In the end, most advertising involves trying to trick people into buying products that they don't need, that don't do what they want, solely because somebody gave them the idea. With the exception of commodity products, it has minimal real-world impact on intelligent buyers except to make somebody aware of a product that they otherwise would not have known about.
The ad makes customers aware of the existence of new products, which means potential customers think, "I know a product that does that," when they need to do something. The problem is that most conscientious consumers then go and search Amazon to find the best product in that category, which basically means that your ad didn't buy you a sale; it bought the industry a sale, maybe, assuming that the person would not have done that search without the ad (which is probably not a valid assumption in most cases).
At least Amazon's "People who bought this also bought" feature actually does a passable job at identifying things that might be interesting to me. It has the advantage of actually knowing the things that I buy. A website like Facebook basically has no prayer.
This explains a great deal about why Google has always seemed like it has a massive case of ADHD, starting lots of projects, then dumping them a couple of years later. None of them got enough attention by any single person for a long enough period of time to evolve from being a pet project into being something that's actually good before it became somebody else's problem.
Keeping a single job only one or two years means that you can't build up any level of institutional knowledge. Admittedly, on the plus side, this means everything gets written down, but on the minus side, it almost invariably leads to an environment in which nobody knows what the h*** they're doing because nobody who is working on a project has any real memory of why critical design decisions were made (unless stuff is documented so thoroughly that those details are all written down, in which case the engineers might finish reading the design specs by the time they're expected to move on to the next project).
Fully learning the architecture of a complex piece of software sufficient to do any real design work (above the level of a basic code monkey) can easily take the better part of a year. If you change jobs every two years, I don't see how you could get anything done; you'd never have time to fully get comfortable with a product before you got yanked off to do something else. That's quite possibly the worst possible way to build quality products; it's like you're still getting your feet wet in the pool when you get unceremoniously yanked out of the pool and tossed onto the basketball court.
A good software company needs to mostly hire people with the expectation that they will be involved in all aspects of the design, not just in the day-to-day coding. Sure, there's sometimes a senior engineer on top who makes the final decisions, but everybody should be contributing at every design phase, redesign phase, etc., which means that everybody needs a fundamental grasp of the overall architecture. That's just not possible if you're changing jobs every couple of years.
More importantly, working on the same project over an extended period of time gives you a sense of ownership, which means you're more likely to take care of the code and improve it. And even if you jump into a project that has been around a while, after a time, you'll get used to it and will take ownership of it. By contrast, if the project gets handed off to somebody else after a year or two, they have no real desire to continue maintaining your code; they have different ideas about how it should be designed. The result is a series of non-stop rewrites, and nothing ever comes out of it except a lot of unfinished code.
Such a short work cycle is just plain bad engineering practice. If it works at all for even one project, it's almost purely luck. Like I said, it explains a lot.
Then eventually the manager gets canned by his/her manager, and the incompetent people end up in other teams where they get canned. In the end, it all works itself out.
The biggest problem is that adding support for something like LaTeX would likely detract from the adoption of web standards like CSS3. Half the browsers wouldn't touch it, which means it wouldn't work everywhere. The other half of the browsers would support it in lieu of improving CSS further. And in general, there would not be the same push to make CSS a full-featured style system. Cynically put, the best thing that could happen in the typesetting world would be for LaTeX to just suddenly go away, thus forcing the rest of the industry to take the time to innovate its way out of the half-assed mess it is in now.:-)
...But that's quite recent, and I don't how many users will have such a setup.
I wasn't suggesting piles of JavaScript as a solution for a normal web page. That's massive overkill. Most web pages really don't need to be perfectly wrapped into multiple pages for printing, etc. For the 99% case, a couple of page break CSS rules will result in a printout that's good enough, and frankly, I can't imagine more than a fraction of a percent of web designers even caring enough to do that. Heck, it took years just to get those CSS properties added to boarding pass web pages, and those are solely designed to be printed.:-)
I was suggesting that it would be possible to write a LaTeX-like typesetter for printed copy using JavaScript. In other words, standardize on HTML (or XML written in a dialect that can readily be transformed into HTML) as the one true document format for pretty much everything, and use it as the source format for creating content in PDF format, printed books, etc. It might or might not even be in a browser. I could see it being a command-line tool written using WebKit or something.
Such a JavaScript formatting engine could be built into the handful of mobile devices whose screens are too limited to handle scrolling. For the other 99% of browsers, it really isn't necessary unless you're creating content for publication.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out.
I've never heard of a company that didn't leave the decision of who to hire up to the teams. Is this person saying that Google hiring is done by HR? That's just a horrible way to do things. Hiring standards vary according to the team because the needs of the team vary according to the team and according to what that person is going to be doing.
More importantly, I've found that above a certain baseline level of technical competence, it's far more important to hire someone who gets along with the team than to hire someone with any particular set of skills. In effect, job postings are just recommendations for what you'd like, not requirements. Unfortunately, people (both on the hiring side and the applying side) tend to read them as a laundry list instead of as a roadmap, and tend to assume that if a person isn't a perfect fit for every little point, then they aren't a good fit for the position. The reality often couldn't be further from the truth. Being a good match for a job on paper is rarely a good indication of whether someone is a good match for the job.
Where I work, our team does a dozen different things, and all of us do several of those things in various proportions. A new hire who can do the things listed in the job description might be able to be a drop-in replacement for somebody who retired, which is certainly the easiest hiring case to make. However, more often than not, we would be just as happy with someone who can take over some tasks currently owned by three other people within the team who already know how to do the things listed in the job description.
Put simply, you don't hire for a position. You hire a person who works well on the team, then you figure out how best to integrate them. That can't be done by anyone other than the project team, because only the project team has a sufficient grasp of all the things that the team does.
Don't know about resetting brain thing, but "how the last page ended" easily happens if something distracts you just as you read last paragraph and flip the page.
Exactly. Also, if the content itself transitions abruptly, you often wonder if you've turned two pages accidentally, which means you have to go back and check the page numbers. That's pretty clumsy.
My browser doesn't do hyphenation or ligatures, the kerning is probably rather bad, and I don't think that the line breaking algorithm is as good as the one in TeX.
Hyphenation is part of the CSS3 draft standard, and is supported by all WebKit browsers and Firefox in one form or another (-webkit-hyphens: auto; -moz-hyphens: auto; hyphens: auto;).
Ligature support is normally part of the OS's type rendering system, and should be used automatically if the font contains the ligatures and if they are properly specified in the font. If they aren't, assuming you already create a JavaScript rendering engine with some sensible text callbacks built-in, it would take only one line of JavaScript to perform the necessary text substitution. And if you want manual control, as long as you use the UTF-8 character set for your HTML content, you can forcibly insert a specific ligature in a particular spot by inserting the right UTF-8 character code instead of the code for the letters that make it up.
Kerning is a matter of your OS's type rendering system, so if you're using an OS that actually understands all those OpenType kerning things, it should do very nearly the same job as XeLaTeX. If it doesn't, get a better OS.
Moreover, there is no reasonable way to set the line length (half of the websites use a very small column, and the other half use the full window width which is generally too wide), and making a table of content is a pain in the ass.
That's not really that relevant to using a specific engine (e.g. WebKit) as a typesetter (which is what I was talking about). What you're talking about is inconsistencies in the way different sites design their content. Now, LaTeX might make two-column content easier, I'll admit, but outside academic papers (for which LaTeX works reasonably well) and newspapers (for which layout is, by necessity, done by hand), that's not exactly a common layout style for publishing.
LaTeX really doesn't have a very good way to say that the end-of-section marker must be on the same page as at least two lines of the previous paragraph
I't called a widow, and you can prevent them with \widowpenalty=10000. By default, they are only discouraged because sometimes they look less ugly that the other alternatives.
No, that's not a widow. A widow penalty tries to ensure that you don't get the last line of the paragraph by itself on the next page. LaTeX provides no equivalent functionality for saying that the line of content after that paragraph (e.g. a \vspace followed by a centered *** section mark) may not be by itself. Nor, AFAIK, does LaTeX provide a way to avoid what I would call widow paragraphs (an entire one-line paragraph appearing by itself) because it renders content a paragraph at a time. As far as LaTeX is concerned, that isn't a widow because the entire paragraph appears on the page.
And while we're talking about LaTeX issues, I forgot one really nasty one that caused all sorts of problems for me. LaTeX doesn't handle UTF-8 very well at all. By default, it inserts no wrapping around the em dash. I ended up adding code to the XSLT that I'm using to produce the LaTeX markup so add a hair space after the em dash, which LaTeX then happily treats as a word break. Prior to that, I was getting the most horrendous overfull and underfull hbox problems I've ever seen whenever an em dash appeared near where a line should break....
However, what you are claiming is not entirely fair. If it's built into CSS then it is almost certainly easier in CSS than in TeX. The point is that due to the capabilities of TeX, you can do things that the CSS designers never thought of (like those crop margins).
Except that due to package incompatibility problems, I ended up writing my own code to do the crop marks because it was easier than getting everybody to work together. I think it would have taken less code to write a paginating typesetter in JavaScript than it took to make LaTeX behave. If I had such pagination code in HTML/CSS, the CSS for those crop margins would once again have been about four lines of CSS once I had an actual div or other equivalent page object representing a printed page.
But anyway, the conclusion is that CSS is higher level and makes anything that fits its model easy. However, many things are simply impossible in CSS.
Only if you don't consider JavaScript. Once you factor that in, about the only thing I can think of that HTML/CSS lacks is a notion of determining which page something will fall on when printed, which as I said, is probably a couple thousand lines of code at most, and maybe just a few hundred. I'm almost tempted to write it some weekend just for fun.
The book replaced the scroll because you could pack a lot more density into something when you have sheets stacked on top of one another instead of wrapped into a tube. That benefit outweighed the inconvenience of having to reset your brain every time you turned the page. However, the point still remains that when you are actually reading the content, it's much easier to read a continuous scroll because you never have to think, "Oh, crap, how did the last page end again?" and flip back.
With software, you don't get higher content density by dividing things up into pages (higher ad density notwithstanding). There are basically only two good reasons to have page-based content in browsers: to format content for printing, and to provide an easy way to mentally bookmark where you are in a book and/or provide citations (go look at paragraph 3 on page 212). Neither of these requires viewing the content a page at a time, however; you could insert a light horizontal rule with a small margin around it and a page number off at one edge, and this would provide the same benefit without interrupting the reading process.
Thus, in my mind, viewing content a page/screenful at a time seems like a tremendous step backwards. It's an unnecessary change that provides no benefit and makes reading clumsier.
Speaking as someone who has spent countless hours writing custom LaTeX macros, bulletproof is exactly the opposite of the word I'd use for LaTeX. As soon as you stray very far at all from academic papers, it suddenly becomes just about the most fragile piece of code I've ever worked with. It's great as long as you never have to do anything custom. As soon as you say the words, "I know. I'll write a custom macro to [...]," you've just crossed the line into despair territory.
To put it in perspective, my novel formatting code is 1545 lines, about half of which are insanely complex TeX macros, versus under 500 lines of CSS that does about 90% of the same stuff (minus the crop marks and page margin bits).
In fact, given what modern browsers are capable of in terms of typesetting, I'd imagine it would be just a few thousand lines of JavaScript to produce a much more fully capable typesetting engine than all of LaTeX put together, but with a lot fewer limitations. For example:
It took 28 lines of LaTeX code to emulate the interaction between the CSS min-width and width properties on a div. (The min-height property, by contrast, took only one line of TeX, which may explain why I found a dozen sites that explained min-height, but no ready-made solutions for min-width.)
LaTeX is really, really bad at math. You have to know how to write your own macros just to subtract one length from another. I'd estimate 75% of the macros I've written have required getting the floating point package involved, which is just a royal pain.
There are three different ways to center. Not all of them ignore the first paragraph indent like you'd expect. So if you're wondering why your centered text is shifted off to the right....
LaTeX mixes code (macros) with text freely (without any delimiters), which means it is often difficult to write macros that are easily readable without adding extraneous whitespace in the output.
LaTeX doesn't have any real notion of floating content on its own, so if you add a drop cap and the paragraph in one chapter happens to be only a single line long, you get to fix it by hand or write some insane code using the FP package calculating the vertical distance between the drop cap marker and the first line of the next paragraph to see if it is greater than one line long. That's almost a hundred lines of code right there, versus something like three lines of CSS.
LaTeX really doesn't have a very good way to say that the end-of-section marker must be on the same page as at least two lines of the previous paragraph, but that it need not be on the same page as the entire paragraph. In HTML, it's just style="page-break-before: never;" and you're done.
There seem to be a thousand different ways to tweak page margins, none of which are universally compatible with various other packages (headers, footers, and other stuff done during the AddToShipoutPicture phase, in particular, if memory serves).
The user community has all sorts of hacks to work around various aspects of LaTeX's design, but these often interact in strange and almost inexplicable ways when you combine them. What makes this particularly problematic is that most of the maintained macro packages aren't much better in this regard. This is actually fairly fundamental in the design; macros are inherently much harder to write than normal procedural code that operates on attributed data like the DOM.
There's something fundamentally bizarre about a typesetter that doesn't know where it just put content, forcing you to add a bookmark and write it into a file, then find out the value on the next pass. Compared with the JavaScript DOM, that's amazingly clumsy.
God help you if you want to do something simple like programmatically redefine boldface to a squiggly underline in a way that is actually robust. In particular, I had endless trouble with the interaction of uwave and/or textbf and other macros causing all sorts of errors whose explanations had absolutely nothi
Nah. It's only at about 9,300 feet. The Air Force has twin-blade rescue helicopters that can land at almost double that. That said, you're right that a lot of smaller single rotor helicopters cap out below that.
I think the more important question is probably what the crosswinds are like.
Yeah, but officially, the purpose was supposed to have been for camcorders and other non-powered devices. Then Sony decided to further abuse the standard by using it for laptops, which was just plain egregious.
Then again, with those tiny laptops they were building, they probably didn't have the power budget for a real FireWire port....
I still cannot believe that if I buy a 5MB ebook, it costs Amazon 20 cents to just send it to me. I guess a 4GB DVD image would cost $164 and a 500MB movie $20? How does Netflix stay in business? As I recall they provide downloads.
In hindsight, the numbers I was remembering might have included the credit card processing fees, in which case it's closer to half a cent or a cent per meg. And since I can't remember the source, it's worth taking with a grain of salt.
Slashdot Mirror
Insurance and to some extent maintenance is a sunk cost. You pay it whether you're driving the car ten miles per month or a thousand. Thus, the only people for whom that enters into the equation are the one who conclude that they can reduce their number of cars by one or more.
Actually, that's pretty easy. About 10% of the asteroids in the belt between here and Mars are mostly metal. The materials are already in space. The problem is not a lack of material or a lack of energy. The problem is a lack of motivation.
As I posted on Facebook the other day, when animals find their local habitat too constrained, they venture out into the wider world to seek a better one. So, too, must we as a species venture out among the stars if we are to thrive.
All the naysayers saying that the Earth can't handle the population don't get it. If we don't face evolutionary pressure to move out of our proverbial parents' house, we're never going to grow up as a species. It is precisely that adversity—that struggle to do more with limited resources—that is the force that drives the human race forward, and as such, it is no more something to be feared than life itself.
Citation needed.
What investments in production capacity? The U.S. hasn't done that in any significant way for as long as I've been alive. It just outsources the labor to some other country where the cost of labor is cheaper.
Don't get me wrong, I think it would be great for the U.S. to invest in production capacity. I'm just not convinced that leaving the money in the hands of the same rich people who have repeatedly failed to invest in that capacity will miraculously cause that to happen. The extremely wealthy do not create jobs. The people who create jobs are the middle class workers who start small businesses.
If you want production capacity, take the money from the rich and give it to the middle class. Some of those people will just buy consumable goods, but the ones who are not barely getting by will look for ways to invest that in things that can make money, including the production capacity you so crave.
And sure, in the end, maybe you've created a new top 1%, but at least some part of that new top 1% will be made up of people who aren't squeezing that last cent out of the market by outsourcing everything to China.
Although you are technically correct (the best kind of correct), that's a rather useless way of viewing money. In the U.S., the top 20% have about 85% of the accumulated wealth, and the top 5% have almost 60%, which makes it a remarkably lopsided distribution, with the vast majority of people living below the mean.
What this means is that if you repeatedly cut the top 1% down to the mean and distribute it among everyone else, it doesn't take long before you have dramatically increased the overall standard of living.
The bigger problem I have with your post is the assumption that the rich have predominantly earned their money. There's earned income, and there's unearned income (capital gains, interest, etc.). The vast majority of working class income falls into the first category. The vast majority of upper class income falls into the latter category. So any tax scheme that does not tax the upper class more than the working class is unfair because it takes away money that the working class have earned to allow the rich to keep more money that they haven't earned.
I was totally wishing I had something like this last week when there were all those hundreds of reporters at Apple's campus.
Maybe it's just me, but I think Steve sightings could become the new Elvis sightings.
After finding a brand of shoes I like, I buy them in bulk. I'm just reaching the end of the stack of shoe boxes I bought four or five years ago. It's almost time to buy shoes again.
As for clothing, I have a closet full of short-sleeve shirts, and a closet full of long-sleeve shirts. Clothes last a long time if you wear them only once per month. Also, my parents often give me a shirt or two for Christmas, which further reduces the need to actually shop for clothes. And I buy white socks in bulk every few years so that they all match (which saves a lot of time while folding them).
So basically, the pattern is that I tend to buy a crapload of what I need when I realize that I need it, and then I don't buy any of that type of item again for months or years. I buy bar soap about once a year. I buy bottles of hand soap about once a year. I buy toothpaste about once a year. And so on. So it's probably not that I buy fewer total clothes than you, so much as that I buy more clothes less often.
You can make high quality products with Chinese manufacturers, but you have to be very selective about which manufacturers you'll work with, and you have to pull random inspections to ensure that they are actually doing the QA testing they claim to be doing. Otherwise they'll send you half junk.
A lot of it also depends on the design work that went into it. If you've done the board layout and testing yourself, repeatedly ordering new test runs until you get a layout with perfect or near-perfect yield, you'll do a lot better than if you order a test run, have a 50% failure rate, and say, "It's okay. When people return it, we'll just send them a new one and toss the old one out."
The main reason to go with China is that it's just about the only place I've found where companies will even talk to you about small-run manufacturing. They've become experts at retooling a factory floor very rapidly for new products, which means that whether your production run is a thousand units or a million units, they can easily accommodate you. Most companies in the U.S., not so much. Thus, if you're a small business that's just starting out, unless you managed to secure the rather sizable funding to build your own manufacturing plant, outsourcing to China is usually the most feasible way to see your design actually turn into a physical product.
You owe me a new keyboard....
Nah. It's a lot dumber than that. Your colleague probably has several friends who have several friends, and if you walk through a few degrees of separation, there are probably at least two paths that connect her to the suggested person.
I mostly see people I've never met as a result of those algorithms, but every once in a while, it lists somebody who I know peripherally.
If only it were actually that good. Every time I see an ad for a company whose products compete with products made by my employer (that I thus almost certainly wouldn't even consider buying), I conclude that they must not be doing much more than a trivial keyword search (and they know who my employer is, so that's just a Facepalm right there).
And as that satellite fell out of orbit a couple of weeks ago, I was summarizing a bunch of random Twitter feeds and news reports on my Facebook feed. As a result, I was seeing all sorts of bizarre ads related to all the cities that I mentioned, like "Travel to Hawaii", followed by "Travel to Ontario".... Completely and totally out to lunch.
Of course, if you asked me what kinds of products I buy more than once in any given year, you'd get the following list:
And that would be the end of the list. If you're advertising anything that's not on that list, it's noise. Given that (with the exception of movies) almost none of the products on the list are regularly advertised on pretty much any website, web advertisements rarely have any real impact on my buying habits. Then again, as the sort of person who will spend three hours browsing Amazon reviews before buying a blender, and the sort of person who mostly buys twentieth-run movies from the $5.99 bin instead of new releases, I'm not sure they'd affect me much even if they covered the products I buy regularly.
The kind of advertisement that does affect me, if you can call it that, is word-of-mouth advertisement. Specifically, if you make a good product, and people give it consistently good reviews, I'm more likely to buy your product. If you make a s**tty product that falls apart in six months, I'm more likely to call up a manufacturer in China and go into business against you (which isn't very likely to happen at all, but is still a heck of a lot more likely than me buying your junk product).
In the end, most advertising involves trying to trick people into buying products that they don't need, that don't do what they want, solely because somebody gave them the idea. With the exception of commodity products, it has minimal real-world impact on intelligent buyers except to make somebody aware of a product that they otherwise would not have known about.
The ad makes customers aware of the existence of new products, which means potential customers think, "I know a product that does that," when they need to do something. The problem is that most conscientious consumers then go and search Amazon to find the best product in that category, which basically means that your ad didn't buy you a sale; it bought the industry a sale, maybe, assuming that the person would not have done that search without the ad (which is probably not a valid assumption in most cases).
At least Amazon's "People who bought this also bought" feature actually does a passable job at identifying things that might be interesting to me. It has the advantage of actually knowing the things that I buy. A website like Facebook basically has no prayer.
This explains a great deal about why Google has always seemed like it has a massive case of ADHD, starting lots of projects, then dumping them a couple of years later. None of them got enough attention by any single person for a long enough period of time to evolve from being a pet project into being something that's actually good before it became somebody else's problem.
Keeping a single job only one or two years means that you can't build up any level of institutional knowledge. Admittedly, on the plus side, this means everything gets written down, but on the minus side, it almost invariably leads to an environment in which nobody knows what the h*** they're doing because nobody who is working on a project has any real memory of why critical design decisions were made (unless stuff is documented so thoroughly that those details are all written down, in which case the engineers might finish reading the design specs by the time they're expected to move on to the next project).
Fully learning the architecture of a complex piece of software sufficient to do any real design work (above the level of a basic code monkey) can easily take the better part of a year. If you change jobs every two years, I don't see how you could get anything done; you'd never have time to fully get comfortable with a product before you got yanked off to do something else. That's quite possibly the worst possible way to build quality products; it's like you're still getting your feet wet in the pool when you get unceremoniously yanked out of the pool and tossed onto the basketball court.
A good software company needs to mostly hire people with the expectation that they will be involved in all aspects of the design, not just in the day-to-day coding. Sure, there's sometimes a senior engineer on top who makes the final decisions, but everybody should be contributing at every design phase, redesign phase, etc., which means that everybody needs a fundamental grasp of the overall architecture. That's just not possible if you're changing jobs every couple of years.
More importantly, working on the same project over an extended period of time gives you a sense of ownership, which means you're more likely to take care of the code and improve it. And even if you jump into a project that has been around a while, after a time, you'll get used to it and will take ownership of it. By contrast, if the project gets handed off to somebody else after a year or two, they have no real desire to continue maintaining your code; they have different ideas about how it should be designed. The result is a series of non-stop rewrites, and nothing ever comes out of it except a lot of unfinished code.
Such a short work cycle is just plain bad engineering practice. If it works at all for even one project, it's almost purely luck. Like I said, it explains a lot.
Then eventually the manager gets canned by his/her manager, and the incompetent people end up in other teams where they get canned. In the end, it all works itself out.
The biggest problem is that adding support for something like LaTeX would likely detract from the adoption of web standards like CSS3. Half the browsers wouldn't touch it, which means it wouldn't work everywhere. The other half of the browsers would support it in lieu of improving CSS further. And in general, there would not be the same push to make CSS a full-featured style system. Cynically put, the best thing that could happen in the typesetting world would be for LaTeX to just suddenly go away, thus forcing the rest of the industry to take the time to innovate its way out of the half-assed mess it is in now. :-)
I wasn't suggesting piles of JavaScript as a solution for a normal web page. That's massive overkill. Most web pages really don't need to be perfectly wrapped into multiple pages for printing, etc. For the 99% case, a couple of page break CSS rules will result in a printout that's good enough, and frankly, I can't imagine more than a fraction of a percent of web designers even caring enough to do that. Heck, it took years just to get those CSS properties added to boarding pass web pages, and those are solely designed to be printed. :-)
I was suggesting that it would be possible to write a LaTeX-like typesetter for printed copy using JavaScript. In other words, standardize on HTML (or XML written in a dialect that can readily be transformed into HTML) as the one true document format for pretty much everything, and use it as the source format for creating content in PDF format, printed books, etc. It might or might not even be in a browser. I could see it being a command-line tool written using WebKit or something.
Such a JavaScript formatting engine could be built into the handful of mobile devices whose screens are too limited to handle scrolling. For the other 99% of browsers, it really isn't necessary unless you're creating content for publication.
I've never heard of a company that didn't leave the decision of who to hire up to the teams. Is this person saying that Google hiring is done by HR? That's just a horrible way to do things. Hiring standards vary according to the team because the needs of the team vary according to the team and according to what that person is going to be doing.
More importantly, I've found that above a certain baseline level of technical competence, it's far more important to hire someone who gets along with the team than to hire someone with any particular set of skills. In effect, job postings are just recommendations for what you'd like, not requirements. Unfortunately, people (both on the hiring side and the applying side) tend to read them as a laundry list instead of as a roadmap, and tend to assume that if a person isn't a perfect fit for every little point, then they aren't a good fit for the position. The reality often couldn't be further from the truth. Being a good match for a job on paper is rarely a good indication of whether someone is a good match for the job.
Where I work, our team does a dozen different things, and all of us do several of those things in various proportions. A new hire who can do the things listed in the job description might be able to be a drop-in replacement for somebody who retired, which is certainly the easiest hiring case to make. However, more often than not, we would be just as happy with someone who can take over some tasks currently owned by three other people within the team who already know how to do the things listed in the job description.
Put simply, you don't hire for a position. You hire a person who works well on the team, then you figure out how best to integrate them. That can't be done by anyone other than the project team, because only the project team has a sufficient grasp of all the things that the team does.
Exactly. Also, if the content itself transitions abruptly, you often wonder if you've turned two pages accidentally, which means you have to go back and check the page numbers. That's pretty clumsy.
Plus his lawyer's fees, unless he was using a public defender.
Hyphenation is part of the CSS3 draft standard, and is supported by all WebKit browsers and Firefox in one form or another (-webkit-hyphens: auto; -moz-hyphens: auto; hyphens: auto;).
Ligature support is normally part of the OS's type rendering system, and should be used automatically if the font contains the ligatures and if they are properly specified in the font. If they aren't, assuming you already create a JavaScript rendering engine with some sensible text callbacks built-in, it would take only one line of JavaScript to perform the necessary text substitution. And if you want manual control, as long as you use the UTF-8 character set for your HTML content, you can forcibly insert a specific ligature in a particular spot by inserting the right UTF-8 character code instead of the code for the letters that make it up.
Kerning is a matter of your OS's type rendering system, so if you're using an OS that actually understands all those OpenType kerning things, it should do very nearly the same job as XeLaTeX. If it doesn't, get a better OS.
That's not really that relevant to using a specific engine (e.g. WebKit) as a typesetter (which is what I was talking about). What you're talking about is inconsistencies in the way different sites design their content. Now, LaTeX might make two-column content easier, I'll admit, but outside academic papers (for which LaTeX works reasonably well) and newspapers (for which layout is, by necessity, done by hand), that's not exactly a common layout style for publishing.
No, that's not a widow. A widow penalty tries to ensure that you don't get the last line of the paragraph by itself on the next page. LaTeX provides no equivalent functionality for saying that the line of content after that paragraph (e.g. a \vspace followed by a centered *** section mark) may not be by itself. Nor, AFAIK, does LaTeX provide a way to avoid what I would call widow paragraphs (an entire one-line paragraph appearing by itself) because it renders content a paragraph at a time. As far as LaTeX is concerned, that isn't a widow because the entire paragraph appears on the page.
And while we're talking about LaTeX issues, I forgot one really nasty one that caused all sorts of problems for me. LaTeX doesn't handle UTF-8 very well at all. By default, it inserts no wrapping around the em dash. I ended up adding code to the XSLT that I'm using to produce the LaTeX markup so add a hair space after the em dash, which LaTeX then happily treats as a word break. Prior to that, I was getting the most horrendous overfull and underfull hbox problems I've ever seen whenever an em dash appeared near where a line should break....
Except that due to package incompatibility problems, I ended up writing my own code to do the crop marks because it was easier than getting everybody to work together. I think it would have taken less code to write a paginating typesetter in JavaScript than it took to make LaTeX behave. If I had such pagination code in HTML/CSS, the CSS for those crop margins would once again have been about four lines of CSS once I had an actual div or other equivalent page object representing a printed page.
Only if you don't consider JavaScript. Once you factor that in, about the only thing I can think of that HTML/CSS lacks is a notion of determining which page something will fall on when printed, which as I said, is probably a couple thousand lines of code at most, and maybe just a few hundred. I'm almost tempted to write it some weekend just for fun.
The book replaced the scroll because you could pack a lot more density into something when you have sheets stacked on top of one another instead of wrapped into a tube. That benefit outweighed the inconvenience of having to reset your brain every time you turned the page. However, the point still remains that when you are actually reading the content, it's much easier to read a continuous scroll because you never have to think, "Oh, crap, how did the last page end again?" and flip back.
With software, you don't get higher content density by dividing things up into pages (higher ad density notwithstanding). There are basically only two good reasons to have page-based content in browsers: to format content for printing, and to provide an easy way to mentally bookmark where you are in a book and/or provide citations (go look at paragraph 3 on page 212). Neither of these requires viewing the content a page at a time, however; you could insert a light horizontal rule with a small margin around it and a page number off at one edge, and this would provide the same benefit without interrupting the reading process.
Thus, in my mind, viewing content a page/screenful at a time seems like a tremendous step backwards. It's an unnecessary change that provides no benefit and makes reading clumsier.
Speaking as someone who has spent countless hours writing custom LaTeX macros, bulletproof is exactly the opposite of the word I'd use for LaTeX. As soon as you stray very far at all from academic papers, it suddenly becomes just about the most fragile piece of code I've ever worked with. It's great as long as you never have to do anything custom. As soon as you say the words, "I know. I'll write a custom macro to [...]," you've just crossed the line into despair territory.
To put it in perspective, my novel formatting code is 1545 lines, about half of which are insanely complex TeX macros, versus under 500 lines of CSS that does about 90% of the same stuff (minus the crop marks and page margin bits).
In fact, given what modern browsers are capable of in terms of typesetting, I'd imagine it would be just a few thousand lines of JavaScript to produce a much more fully capable typesetting engine than all of LaTeX put together, but with a lot fewer limitations. For example:
Nah. It's only at about 9,300 feet. The Air Force has twin-blade rescue helicopters that can land at almost double that. That said, you're right that a lot of smaller single rotor helicopters cap out below that.
I think the more important question is probably what the crosswinds are like.
Yeah, but officially, the purpose was supposed to have been for camcorders and other non-powered devices. Then Sony decided to further abuse the standard by using it for laptops, which was just plain egregious.
Then again, with those tiny laptops they were building, they probably didn't have the power budget for a real FireWire port....
Helicopter.... Nothing fancy, just something with proper blade heaters, for obvious reasons. :-)
In hindsight, the numbers I was remembering might have included the credit card processing fees, in which case it's closer to half a cent or a cent per meg. And since I can't remember the source, it's worth taking with a grain of salt.