aycangulez

True. What often seperates a good speaker from a mediocre one is how it behaves at high volumes. Most speakers made for home use regardless of the price lose composure when cranked high. The main culprit is usually the dome tweeters (a type of hi-frequency driver) that start to compress at high volumes. The solution is to use a compression driver (CD) with a waveguide but mostly for aesthetic reasons, there are virtually no commercial speakers on the market that use CDs.

The alternative is to use public announcement (PA) speakers. Virtually all of them are equipped with CDs, but they are relatively large, and unless you have a dedicated listening/home theater room, they won't really fit a home's decor well.

It occured to me that having the month before the day is the most practical solution because the most important piece in a date is the month as years change only every 365 days or so, and a day gains meaning only when associated with a month. In other words, the month, being the most salient piece comes first.

I still use Photoshop 6.0 circa 1999. It loads in a few seconds max, and it has all the core functionality necessary for web graphics work. In fact, even PS 5.5 would do fine because it was the first version that supported Save for Web.

If you are using the latest version of Photoshop for web work only, you are wasting time and money for tons of features you don't really need.

Looks very similar to Blockout from 1989: http://en.wikipedia.org/wiki/Blockout

In Blockout, you had a transparent falling block so you could see what was below.

I strongly believe that the following excerpt from the article directly applies to any line of work including software development:

"I don’t know if an artist can last by meeting the current public taste, the taste from the last quarterly report. I don’t think you can last by following demographics and carefully meeting expectations. I don’t know many lasting works of art that are condescending or deliberately stupid or were created as content.

Don’t tell me I’m a brand. I’m famous and people recognize me, but I can’t look in the mirror and see my brand identity.

Keep talking about brands and you know what you’ll get? Bad clothes. Bad hair. Bad books. Bad movies. And bad records. And bankrupt businesses. Rides that were fun for a year with no employee loyalty but everyone got rich fucking you. Who wants that? The answer is purity. We can afford it. Let’s go find it again while we can."

I have been following Fingleton, the author of this article for quite a while. His main thesis that "Japan's lost decade is an illusion" has not changed much over the years. In fact, he was among the group "Japan bashers" in the 90s, and their main argument was that Japan's Ministry of Finance (MOF) was intentionally trying to paint a grim image of Japan to gain advantage in trade negotiations. This argument holds little water these days: it is next to impossible to hide information about the true state of a country when access to information is so easy thanks to the Internet.

Fingleton also claims that Japanese are early adopters in technology, which is only partly true. Japanese, in general, prefer to excel in something by using manual skills and they take great pride in that. They resort to technology only when manual skill is not enough. Making good cars require industrial robots so they have plenty of them, but in other parts of the industry, adoption of advanced technology can be quite limited. In other words, Japanese companies often find themselves at local maximums as compared to their American counterparts. Just look at the current state of Japan's once great electronics companies: Sony, Panasonic, Sanyo, NEC, Hitachi, etc. Only Canon seems to be doing fine these days.

Joel claims that Trello can be used for kanban. This is not true because Trello doesn't support WIP (Work-In-Progress) limits without which you don't have kanban.

If you want to know your team's capacity, you have to limit the number of tasks they work on at the same time. Once you limit WIP, several interesting things will happen:

* A backlog of tasks will emerge.

* You will be able to measure how much time is spent on each task.

* Tasks will get finished faster.

The first two results are not very surprising because by introducing WIP limits, you have effectively eliminated multitasking, but how on earth, do tasks get finished faster?

Unlike computers with multiple processor cores, our brains have one or at best two cores. Without WIP limits, when there are too many tasks to work on, we spend more time on switching tasks than the tasks themselves.

Bottlenecks become visible. Since everyone is working on a limited number of tasks, some finish theirs on time, some get overloaded, and some cannot finish their work because they need input from those who are overloaded. Team members with free capacity can help those who are overloaded. Better yet, they can even come up with ideas on how to fix the newly discovered bottlenecks.

Disclaimer: I am the author of http://flow.io , a lean project management application based on kanban.

My favorite quote from the article: "Shrink your important code."

and he explains why:

"There was a paper recently that noted that all of the various code quality metrics correlated at least as strongly with code size as error rate, making code size alone give essentially the same error predicting ability. Shrink your important code."

You are absolutely right that manually updating hours is a huge chore and not surprisingly it is universally despised. Making estimates beforehand in scrum is also problematic because it doesn't involve the time spent in previous phases as you pointed out. Kanban, however, solves the problems inherent in scrum, and virtually all digital kanban solutions automatically track the time for you in each phase of your workflow.

So, it is possible to measure productivity relatively painlessly in kanban as it limits work in progress (discourages multitasking, reveals bottleneceks in your workflow). Kanban also takes idle time into account (ex: time spent waiting approval from the management or another dept). See http://flow.io/how-kanban-can-help-you-measure-productivity.... for a brief overview of kanban's benefits.

Disclaimer: I am the author of flow.io, a lean project management app based on kanban.

I have always had an inkling that video games should be considered as applied math. According to Tarn, the author of Dwarf Fortress, who also has a Ph.D in math, making games "scratches all the same itches" as math. That sounds just right to me.

These results were expected by neuroscientists. Different senses are encoded differently in the brain. So, the subjects were unable to link them at first. The surprising thing here is the speed the association between tactile and visual encodings happened, and the article makes that clear.

Not really. It is actually the opposite. See: "Harman debunks youthful music myths" http://news.ycombinator.com/item?id=2427217

The author refers to Don Reinertsen who is a proponent of kanban in software development. For a brief explanation of kanban and how it can help improve estimation, see: http://flow.io/how-kanban-can-help-you-increase-your-teams-c...

The primary function of sleep is to permanently store the things learned during the day (long-term potentiation). Although different people need different amounts of sleep, those who need less usually find that they sleep longer if they learn challenging new material (e.g. a new language). That is the reason why babies sleep the most. Their brains are empty sponges constantly absorbing new information.

The interview mentioned in the article can be found at http://www.foxprohistory.org/interview_wayne_ratliff.htm

I think the real gem is at the end of the article:

"Many things that don’t look optimal are in fact optimal once you take the necessary constraints into account. For example, software that seems poorly designed may in fact have been brilliantly designed when you consider its economic and historical constraints. (This may even be the norm. Nobody complains about how badly obscure software was designed. We complain about software that has been successful enough to criticize.)"

If everyone is complaining about a different part of your software, that probably means just nitpicking. If the complaints converge on a feature or two, then you should absolutely listen to what they have to say. King is right on the money on this one.

Although there is clearly a grade inflation, the correlation between student selectivity and average GPA should also be noted:

"As a rough rule of thumb, the average GPA of a school today can be estimated by the rejection percentage of its applicant pool:

GPA = 2.8 + Rejection Percentage /200 + (if the school is private add 0.2)

Non-selective public schools (typically with 15 percent rejection rates or less) with GPAs in the 2.8 range or less tend to have only modest grade inflation. Some have none."

I don't want to discourage anyone, but you are practically distracting yourself from building a product by learning how to program. Getting really good at something takes many years of practice, and the program you write will likely be full of problems you are ill-equipped to fix.

Facebook isn't elegant enough for Apple. Nor Steve needs any "synergies" to sell more products.

Great insight: "The thing that separated Steve Jobs from other people like Bill Gates - Bill was brilliant too - but Bill was never interested in great taste. He was always interested in being able to dominate a market. He would put out whatever he had to put out there to own that space. Steve would never do that. Steve believed in perfection.”

Liked the philosophy behind the text:

"A word about style and efficiency. As you will see, I tend to write programs in _VERY_ small, easily understood pieces. None of the procedures we'll be working with will be more than about 15-20 lines long. I'm a fervent devotee of the KISS (Keep It Simple, Sidney) school of software development. I try to never do something tricky or complex, when something simple will do. Inefficient? Perhaps, but you'll like the results. As Brian Kernighan has said, FIRST make it run, THEN make it run fast. If, later on, you want to go back and tighten up the code in one of our products, you'll be able to do so, since the code will be quite understandable. If you do so, however, I urge you to wait until the program is doing everything you want it to.

I also have a tendency to delay building a module until I discover that I need it. Trying to anticipate every possible future contingency can drive you crazy, and you'll generally guess wrong anyway. In this modern day of screen editors and fast compilers, I don't hesitate to change a module when I feel I need a more powerful one. Until then, I'll write only what I need."

Norvig's pet peeve: 'Programmers and product managers who can't think about their product from the user's point of view. As Alan Cooper puts it, "The inmates are running the asylum."'

Indeed.

"A glass plate from 1880 still has more resolution than a Canon 1Ds-MkII" says it all.

Best quote from the article: "Alan Kay always said that any problem in Computer Science could be solved by adding another level of indirection."

Cray Y-MP Specs: http://en.wikipedia.org/wiki/Cray_Y-MP

I disagree. Rounded rectangles are a signature Mac OS user interface feature. Thanks to post-Steve Jobs Apple, there is renewed interest in everyhing Apple, and rounded rectangles are truly everywhere. You would have a hard time finding a popular web site not using them.

What is really interesting in this story is not the algorithm itself, but how Steve Jobs convinced Bill Atkinson by taking a walk outside with him to show how common rounded-corners are in "real-life".

I still remember the day I compiled an example program that came with Borland's Turbo Pascal and Turbo C++ compilers. This program was designed to showcase Borland's text-mode user interface library called Turbo Vision, and apart from the programming language used, it ran exactly the same.

Turbo Pascal took just a few seconds to compile the example (no surprises there), but Turbo C++ took several minutes. This was back in the 90's. It seems nothing has changed since then. Sad.

Unfortunately, the same mentality applies to universities, too. They love to build new buildings instead of hiring the best faculty.

A free plan is often a replacement for advertising spending. It gets you users who wouldn't otherwise consider using your product, and you hope that they would tell their friends about it, and some of those friends would eventually pay.

Here is an extreme example: If I remember it correctly, MySQL's conversion rate was quoted as about 1 in 1000. If they didn't distribute the entire product for free, they would have much less market penetration, but certainly earned much more. Had they chosen that route, they wouldn't be able to sell the company for a cool billion.

Nothing in life is free. If you want a lot of users, and don't have the advertising budget for it, you give some or all of your product away for free.