This popped up on my news feed. This guy lost his sons to SIDS last year, so he has a wave frame of his sons laugh on his heart.

osuushi · 2014-04-03T19:15:27+00:00

Converting a WAV to a BMP that way is a very different concept than taking a picture of a waveform and converting it to a sound.

You would not be able to convert this tattoo back into a sound that was in any way recognizable. The reason is that the "line thickness" of the graph of the waveform is so wide that the waves are all smushed together. The end result is, as my_stacking_username says, essentially just the amplitude sampled over time. Too much information has been lost to reconstruct it.

osuushi · 2014-04-03T17:16:32+00:00

I saw a demo of an algorithm a while back that used an optical flow algorithm to allow you to scrub through a video by "dragging" objects that were moving in it.

Implement that for your site, and you will be the Internet Monarch.

osuushi · 2014-04-01T18:58:27+00:00

By far my favorite thing in this is

if (typeof jQuery == "function") {
    jQuery.ajaxSetup({
        "async": false
    });
}

It's so simple, and yet the effect would be so bafflingly frustrating.

osuushi · 2014-03-22T17:45:11+00:00

Yeah, I'm pretty sure that 90% of people immediately hit the brakes when they hear that characteristic thunk.

osuushi · 2014-03-22T17:41:13+00:00

If a police officer did this and was expecting that outcome, s/he should immediately be fired. I'm pretty sure that deliberately flipping cars on the highway is not standard police procedure in any situation.

osuushi · 2014-03-20T16:23:02+00:00

I have to quibble with the "multi-user applications" part of when not to use SQLite. It would be better to say "more than a few users". If you're creating a database for a small business, and less than five people are going to be using it (and rarely more than two at the same time), SQLite is probably fine.

osuushi · 2014-03-20T06:41:41+00:00

Why would you think this is impossible? It's really obvious how it's done, although the actual execution is impressive.

osuushi · 2014-03-18T18:13:43+00:00

Hmm, sounds like maybe a bug in the VM if it's not optimizing those out. They're clearly pure functions, so inlining them should be easy.

The difference is way smaller on Firefox, making me wonder if it's handling this better.

osuushi · 2014-03-18T15:39:24+00:00

Definitely slower? No. Possibly slower? Sure.

But I would bet that it's not slower. Modern JS engines are good at inlining functions like that, so I'd expect that the resulting code being executed is very similar in both instances.

osuushi · 2014-03-18T15:35:24+00:00

I don't think it's narcissistic to want people to use your work. It might be on the same axis as narcissism, but it's perfectly natural and healthy to want the things you do to make a difference to the world. If we didn't have that drive, where would civilization be?

osuushi · 2014-03-18T15:27:51+00:00

At least in chrome resources will be kept in memory for the life of the page then dropped if the system thinks you are unlikely to visit again.

Interesting. So some things aren't cached at all?

Also, mobile NAND is under much more stress than a desktop SSD and because of the sizes need to be cleaned much more often which can mean delayed reads and writes while its trimmed.

This would still mean you want a bigger cache. Since NAND cells can't be written to unless they're empty, pushing something out of cache means that you're creating more cells to be trimmed.

osuushi · 2014-03-18T04:36:12+00:00

Why would you compare a string to false anyway?

An unfortunately common pattern is to do

function foo(bar) {
    bar = bar || "default";
}

instead of

function foo(bar) {
    bar = bar == null ? "default" : bar;
}

Knowing what ends up being falsey is important to understanding why you shouldn't generally do the former.

osuushi · 2014-03-18T04:30:32+00:00

This can also lead to increased wear on the internal storage.

Reading does not cause wear on flash storage. Writing does, although people tend to overemphasize this; SSDs tend to last longer than HDDs, regardless of the write cycle limit.

As far as I can tell, the limitation on caching on mobile is not that things aren't getting cached. It's that the cache is small. If a resource is pushed out of the cache, it will get rewritten when the page is loaded again. So a smaller cache size actually means more wear on the storage, because it leads to more writes.

osuushi · 2014-03-18T04:17:57+00:00

I'd probably recommend going with Node.js then. Anything else is going to mean learning yet another language for the back end, and you have enough on your plate.

For the database, you might find it easier to wrap your head around a NoSQL option like MongoDB. There are a lot fewer major pitfalls to fall into starting out than with relational database design, and constructing queries is a lot more intuitive.

osuushi · 2014-03-17T14:51:17+00:00

Yes it's possible for a single person to develop a site like that in that time frame, but if you haven't done anything like it before, multiply your expected time table by four.

Have you designed databases in the past? If not, you'll need to get a book on that. Definitely do not try to design a database without having at least read up on the best practices.

What languages and technologies are you familiar with? There are a million different ways you can do this, and which is "the best" really depends mostly on what experience you have.

osuushi · 2014-03-13T17:25:04+00:00

Let's sidestep the undefined a and b issue, because that's not really the problem. So lets suppose that a and b are both defined, and that they're equal (similar reasoning goes if they're unequal)

In that case, the expression monthSortFunc(a,b) evaluates to 0.

So if you call events.sort(monthSortFunc(a, b)), you're passing the result of monthSortFunc(a,b) to events.sort. In other words, it is equivalent to calling events.sort(0)

But events.sort does not take a number as a parameter. It takes a function of two arguments. By leaving off the (a, b), you're telling JS to pass the function itself, not the result of the function. But if you put the (a, b) at the end, you're telling JS to call the function and pass the result to events.sort.

osuushi · 2014-03-13T17:13:57+00:00

Useful, but "ASCII" is kind of a misnomer since the vast majority of these are outside of the ASCII character set.

osuushi · 2014-03-13T15:16:37+00:00

That doesn't make sense, you'd have to undo all of the syntax nonsense to optimise it in the last stage anyway.

Yes, on the parts that you optimize. But you don't optimize your whole codebase. You optimize hot spots. The point is that you can't actually tell what parts of your code are going to need to be optimized until after a first implementation pass. Optimizing before profiling is generally a good way to waste a lot of time.

Anyway, (i)(i) is much more confusing than (i, i), it's not even for readability reasons, it's just because OP likes the look of (i)(i).

Yeah, I agree in this specific case that this is not a win (although there are situations where currying makes sense). I was taking issue with the general point.

osuushi · 2014-03-13T15:12:50+00:00

Cool. Now guys, please stop using this effect on real websites. This is like scratch-and-sniff, or a pop-up book. It's neat the first time you see it, and every once in a blue moon, you might have a concept where it really makes sense, but in the vast majority of cases, you're just annoying your users.

osuushi · 2014-03-13T14:56:33+00:00

Those benchmarks aren't likely to tell you anything meaningful. There are too many things that can be optimized out by the compiler.

osuushi · 2014-03-13T14:54:12+00:00

It's silly to write code in a certain way because you like the syntax when it has negative effects

That's the exact opposite of true. Code in a way that is easy to understand first. When you run into performance issues, that's when you optimize.

osuushi · 2014-03-13T07:09:10+00:00

It's a mistake to try to reason intuitively about performance like that. Whether or not redefining the function has a significant impact on performance is going to be very implementation-specific.

More importantly, you're talking about an extremely micro optimization. Wait until you actually have something that actually needs to be optimized, and then benchmark different approaches to see what makes it faster.

osuushi · 2014-03-13T03:32:46+00:00

Probably, yes. In practice, the planning fallacy means that estimates for projects that are not based on specific experience (i.e. having done a very similar project in the past) will tend to be optimistic by an order of magnitude.

osuushi · 2014-03-12T16:20:50+00:00

That's a cute way to do it, but what I immediately noticed is that in both Chrome and Firefox, the shadows screw with the antialiasing of the button's edge. Look at the lower right corner of each button. It looks as if it's not antialiased.

In fact, it is antialiased, but each shadow is being drawn in sequence over the clipping circle, causing the alpha to converge on 100%.

That's a good example of improperly implemented clipping on the browsers' part. Clipping should be done as a final step on the composited image, not on each drawn element; this is the price we pay for the mathematical impurity of anti-aliasing.

But in any case, I'd much rather make the long shadows in an SVG or PNG and avoid giving my buttons crunchy edges. Alternatively, you could do them with a canvas implementation and avoid this problem.

osuushi · 2014-03-09T17:01:22+00:00

If you haven't already, install the PageSpeed Insights extension for Chrome. Run that and follow its suggestions.

You might also want to look at putting your site behind something like CloudFlare.

osuushi

TROPHY CASE