Any continuous function can be described as a sum of sinus-functions with different amplitude and frequencies, given that the maximum frequency is limited. Finding these amplitudes can be done quite easily using something called discrete fourier transform. A lot of audio and imaging technology is based on this theory, jpeg compression for example, and almost any audio and signal-processing.
The downside is that very few mathematically interesting functions have limited frequency. While this is not a problem for signal processing, as our senses usually cannot sense the difference, in math it's very easy to see the difference even if you cut off at really high frequencies: http://upload.wikimedia.org/wikipedia/commons/d/d4/Synthesis...
In other words, if one tried to do the Batman curve using Fourier transform, the formula to get sub-pixel consistency would be extremely long.
This is easily solved in practice by segmentation. Images are segmented in blocks, and each small block can be well approximated by a low frequency content, but block boundaries can contain discontinuities. If you look at the wolfram alpha source, that's exactly how those images are constructed -- they are combinations low frequency segments, most likely obtained through fourier analysis.
Another trick used in frequency domain compression is they don't impose a hard cut-off of frequencies (truncation); instead they specify weights according to image quality, and lower are assigned to high frequencies, and those weights control the precision of each frequency.
All this works because real signals happen to be concentrated in certain frequencies, with a few discontinuities in between.
I've always been very against these angular versions of basic js functions because it requires everyone on the team to learn them and it puts you even deeper into the angular lock in swamp, hindering you from eventually changing your view-framework in the future. Any takes on this?
I like the data binding of angular but try to restrict angular coming in contact with "core" code. As example we hardly write any services, we just use them to hold an instance of plain js-classes that can easily be reused in non angular projects.
Services such as $interval or $timeout are very simple - $http is also a fairly simple service to replace too. I don't really view it as much of an issue when it comes to lock in or migration, there are usually far more perilous pitfalls when it comes to lack of being able to migrate, such as bad app architecture or hacks.
I agree with you. It doesn't matter how thin the wrappers are or whether they preserve the API, the problem is all code is supposed to call them.
It's no problem to call $timeout in your Controller code or whatever, but what if you want to require a module that uses `setTimeout`? Either the module has to have some way of passing in the timeout function it should call, or you'd have to have a shim that monkey patches it or something.
Services like $timeout and $interval are basically just thin wrappers around their vanilla JS relatives(setTimeout and setInterval), there are more examples like this.
The APIs look identical, some with a little added functionality - but the primary reason for the AngularJS wrappers is that they'll automatically call $scope.$apply() for you, so that you don't have to do it yourself.
Everything is accessible, it's just a question of how many layers of plastic you have to remove to get there. I wouldn't call the bus he found in this article user accessible but he still found it by removing some cover.
It's not only hard, it's impossible to play with my touchpad. It has some kind of anti-interference detection so that it can't be moved/clicked shortly after typing on the keyboard, "smart-check" they call it. This "feature" can't be turned off completetly! It just has a slider going from min-max where max requires almost one second delay after typing and min only prevents simultaneous motion/typing, which is what you need if you want to move+shoot simultaneously in this game. Lenovo+synaptics crap.
I'm not into the specifics of https but i've been writing a lot of gateways for other protocols and it's never as easy as "just forward the message". Protocols some times have state that the proxy must be aware of and sometimes the forwarding is conditional which means that the proxy must understand both types of protocol and be able to act based on information in it. Say for example you want to block all requests to a specific resource, if your https server knows about this you might be able to reject the request before you decrypt everything of it.
Because IRC, ICQ, MSN, Lunarstorm, Instagram, all those PhpBB and vBulletin boards we all used to use (and still do) was never even "remotely usable"....
The only way facebook differs to most of them is that it markets itself to being a general social network, not one specifically about programming, horses, biking, photography or another specialized field. Finding your friends by alias was never a problem, it's just like asking someone for their phone number.
If you know the management is not technically competent, the responsibility also lies on the developer to communicate things on their level. If they ask how long will X take, you don't answer 1 day, and then another day to test it. You answer 2 days. If that's outside their budget then forget about that feature and let sales find a new feature they can sell that can be developed within the budget.
This also boils down to the ego thing, many junior developers are proud to give short estimates to show off how quick and good they are at their work. But those short estimates are always always always just the estimated time to get a quick prototype working, where things are configured as you go in the debugger, not something that is robust and will work together with the rest of the application in a customer deployed environment. Estimation is really where you can see the difference in an experienced engineer and a non experienced one.