An explanation of the C programming language for programmers used to Python, Ruby etc.
http://www.chiark.greenend.org.uk/~sgtatham/cdescent/
An explanation of the C programming language for programmers used to Python, Ruby etc.
http://www.chiark.greenend.org.uk/~sgtatham/cdescent/
I liked this – exhaustive testing of 32-bit floating point math is practical.
http://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/
The book was too big to go into print, but some of it was released on the companion web site.
This looks interesting
This is a REST client that can send thousands of parallel requests and aggregate the responses.
https://github.com/alexbw/novocaine
This is the code used by the author (Alex Wiltschko) in several cool iOS apps that he released last year. I don’t know anything about the code yet, it’s on my list of things to look at, but the apps are cool.
Oh, and there’s also
http://theamazingaudioengine.com/
which I haven’t looked at either, yet.
It seems like Bootstrap is taking over the (web) world. Here’s a Boostrap showcase site:
http://builtwithbootstrap.com/
The random library introduced in Boost, put into TR1, and now part of C++11, is awesome. This is one of the must-use bits of the C++ Standard Library. It’s solid and pretty fast. My recommendation is that, unless you are really an expert, you use <random> for your random number needs, and be done with it.
Engines are sources of random numbers; an engine returns unsigned integer numbers uniformly distributed in a range between a predefined min and a predefined max. Typically, this is the min and max of the unsigned integer range.
engine e; v = e();
Distributions turn the uniformly distributed values into a desired distribution; linear, normal/gaussian, exponential, gamma, Bernouilli, etc.
dist d; v = d(e());
That’s it! Well, the devil is in the details, but the details aren’t much more daunting than that – you need to pick an engine and a distribution, and you probably want to seed the engine, and you may need to worry about thread-safety. And of course, the standard uses much longer names than engine and dist.
Oh, and always use a distribution. It will do the mapping of random integers into your desired range properly.
Random Number Generation in C++11 is the proposal to put <random> in the C++11 standard library. It’s also pretty readable. It has good sample code. If you’re going to read one thing on <random>, read this, because it clearly explains what engines are and what distributions are.
The C++ Standard Library: A Tutorial and Reference, Second Edition, by Nicolai M. Josuttis, has a chapter on <random> that’s pretty good.
Ori is a research project from people at Stanford University. It’s worth taking a look at.
http://ori.scs.stanford.edu/#publications
Peter Seibel wrote a piece this past weekend on code reading – or rather, challenging it:
I have to disagree. Or rather, I feel like he’s describing our current (defective) world, and taking it as a given that it’s how things should be.
Most code is unreadable. That is not a good thing, because it blunts or prevents one of the two major ways that you get better at something.
One way to get better is to just do it. And in fact, you will never get better at something unless you do it – you can theorize or otherwise gather information all you want, but that won’t help you when it comes to performing. However, there’s a limit to learn-through-doing, and that is that there’s just you, and you can only try so many things.
The other way to get better is to learn from others. Sometimes, but rarely, you can learn from them in person. But this doesn’t scale, so most learning is done through studying the output of others. You examine architecture, you deconstruct art, you read books.
It’s actually a shame that you need to decode programs in order to learn from them. While there is something to be said about the effort you put into learning something, it should not be herculean unless the payback you get is equally large.
In the past few years, I find myself rewriting programs to make them easier to read. I do this for myself, because I’ve found that I quickly forget exactly what I was doing, and if I have a hope of picking something up months or years later, I need to be able to read it. Fortunately, the same effort to make it more readable also makes it easier to work on, so it’s not lost effort.
And one thing really struck me, and that was the complaint that “in order to understand code, I have to rewrite it.” That is not a complaint, that’s a description of every other learning activity I’ve seen. If you want to really understand how a writer writes, you try to write in their style. For an artist with phenomenal skill or technique, you paint like them so you can learn it.
You don’t really understand something until you can make it.
Reading is an important step to understanding.