882 karma · joined September 4, 2012
[ my public key: https://keybase.io/alwaysbcoding; my proof: https://keybase.io/alwaysbcoding/sigs/ES-ODI1v11tS_xq38nxpRtSoFMBs30d--AiC25_1s3g ]
http://mobandmultitude.com/2013/07/02/the-nsa-comes-recruiti...
I mean, I'm new to this game but did you even call it "coding" in 1996? To me just the word "coding" represents a kind of coolness factor that I doubt existed around programming in the mid 1990's. It used to be a nerdy thing, something you had to be 'smart' and work at a big company to do. Now tech is cool, the game has completely changed. I mean were startups even a thing in 1996? Were hoodies, mac laptops, red bulls and coding on rooftops popular? Because of things like Github, Ruby on Rails, awesome screencasts etc. I think it's just gotten more fun and productive to be a programmer and the lifestyle has more of a mainstream draw than it used to.
The other big plot line in 2013 that wasn't there in 1996 is the impending genocide of universities in America. Higher tuition rates, lower employment rates, it seems like the learn to code movement is the Newtonian "equal and opposite reaction" to the imminent death spiral of 4-year degree programs in America. I think we're going to see a ton of innovation from the "learn to code" schools in the next few years, innovations in education that the Universities won't be able to match, and the "learn to code" schools are going to kick the living crap out of colleges when it comes to where people choose to spend the money they have allocated for education.
It does a really good job at showing the relationship between HTML + CSS
* You write tests in accordance with a pattern:
1. Arrange
2. Act
3. Assert
4. Annihilate
If you annihilate your test data with configuration options, and you abstract your "arranging" into factories and custom methods, then every test you write should be exactly three lines. When I learned this it gave me a consistent mental framework to think about how to write good tests.
* Test the interface not the implementation:
This was an eye opening realization about what to test. If you haven't seen it yet, watch Sandi Metz' incredible RailsConf talk - http://www.youtube.com/watch?v=URSWYvyc42M - it's so good
* Stubs:
Stubs are exactly like the viruses' that we learned about in biology class. You load them up with a value then they literally latch onto a method and inject that value into it. When you're just starting out with testing, effective use of stubs can get you really far, and only when you start hitting the limits of practicality is when you need to think about bringing in something more complicated.
* Testing isn't easy per se, but it is definitely enjoyable if you focus on making it that way
* Cucumber is pretty stupid, don't waste your time with it
http://www.aicpa.org/BecomeACPA/CPAExam/ExamOverview/Downloa...
If you look at the winners from 1982 (exactly 31 years ago) someone named Joy Dianne Catalano from California had the second best score in the country. So looks like that claim is legitimate.
source: I ran a CPA Exam startup and know wayyy more than anyone ever should about the CPA exam
For example, five years ago, if you wanted to make a Redskins highlight video, you would have to record every Redskins game - which required a TiVo and some sort of video capture card hooked up to your TV set - transfer them to your computer, then parse out all the big plays and put them into a highlight video. It was a very high-friction time consuming process.
Now you can subscribe to NFL.com and get videos of every NFL game and the coaches film, and the radio calls, immediately after they air with big play markers already tagged. So if I wanted to make a highlight video or a database of every big play from the season, it's a pretty painless process.
Because it's getting easier for motivated fans to produce content such as highlight videos, or analysis on sports, I think we're really going to see an erosion of sports reporting on networks like ESPN, as slowly their only purpose becomes live broadcasts. We're going to start sourcing our sports content from podcasts that we like, or a youtube channel that produces good content as opposed to "whatever garbage espn has on at the current time". So anyway there's opportunity for third party sports content.
*
This is a far more interesting question than it might seem at first glance, and it deserves some attention because it tells us something fundamental and wonderful and just bloody awesome about the universe.
But I don't know how to tell the story succinctly. So I'm going to do that thing I do. I am very, very sorry. Please feel free to move on if this strikes you as tiresome.
Consider the Earth, and you on it. You're not floating freely, so clearly something's going on. We call that "gravity." We can call it, in the most generic sense, an interaction: you and the Earth are interacting somehow, and that's what's keeping you from floating freely.
We can then ask what the speed of that interaction is by putting it in these specific terms: How much time will elapse between your changing your position relative to the ground and your beginning to fall?
Yes, it's the Wile E. Coyote problem. Wile E. Coyote runs off a cliff, floats in mid-air long enough to hold up a sign that says "Help," then begins to fall.
Clearly that's an exaggeration. But just how much time does elapse, in real life, between stepping off a cliff and beginning to fall?
We can approach the problem naively by remembering that all propagating phenomena in the universe are limited by the speed of light. Given that fact, it makes sense to hypothesize that the time between the moment when Wile E. steps off the cliff and when he begins to fall will be equal to or more than the distance between him and the ground divided by the speed of light. It certainly can't be less, right?
We can then construct a set of very, very precise experiments with very fine tolerances — probably involving electromagnets and lasers or something — to test this hypothesis.
And then we can find that we're totally goddamn wrong.
To the absolute limit of our ability to measure it — and our ability to measure it is really good, since we used electromagnets and lasers and other expensive science things — when an object is dropped, it begins falling instantaneously. Not after a very small interval of time, but absolutely instantaneously. As in zero time elapses between dropping and falling.
This is fairly earthshaking, really. Because it implies that somehow a "signal" of some kind is getting from the ground to Wile E. faster than the speed of light. Which is supposed to be impossible.
I'm going to skip ahead a bit here, because I don't feel like explaining the entire theory of general relativity, and it won't be that useful in answering the question anyway. Suffice to say that no, no time elapses between dropping and falling, but at the same time no, no signal or interaction has to propagate upward from the ground to Wile E. in order to make him start falling. In fact, what's going on is that Wile E. is always falling, due to the curvature of spacetime created by the Earth. Whenever he's standing at the edge of the cliff, on the ground, the ground beneath his feet — paws? — is arresting his fall by, effectively, pushing up against him. The very instant that's removed, he starts falling.
So in that sense, gravity has no speed. Because it doesn't actually propagate through space. One way to look at it is to say the gravitational field fills space, so wherever you are, you're already being affected by it all the time. Another way is to say that gravitational essentially is space, so it affects you simply by virtue of existing. The two are essentially equivalent English translations of the equations that actually describe the phenomenon.
But okay, that's half the problem. The gravity of a static body fills space, or is space, and as such can't be meaningfully said to have a speed. But what about the gravity of a changing body? Like you said, what if "suddenly a black hole appeared?"
Well, the answer of course is that that never happens, ever. Gravitation doesn't suddenly anything; macroscopic things don't just appear out of nowhere, and teleportation is impossible. So we don't have to think about that … and in fact we couldn't get meaningful answers if we tried.
But things do move. The moon's moving relative to the surface of the Earth; we can tell, even apart from the fact that we can see it up there, because the moon is the major contributor to the tides, and the tides rise and fall. But what's the relationship between the moon's position in space and the tidal acceleration on the Earth? Are the two somehow always in perfect sync, or is there some lag? If so, how much, and in what direction?
That's actually a much harder question to answer than you might think. There was a now-infamous paper some years ago by a fellow named Tom Van Flandern (recently passed, God rest his soul) that asserted that the change in gravitational acceleration in a dynamical system actually propagates many times faster than the speed of light — at least twenty billion times faster than the speed of light — but not instantaneously. This got a lot of attention at the time. If the propagation speed of changes in spacetime geometry were equal to the speed of light, that'd be fine. If it were literally instantaneous, that'd also be fine, more or less, though our theory would need some tweaking. But faster than c but still finite? That was really hard to explain.
It turned out not to be a problem though. Because Van Flandern just made a mistake in his paper. See, the relationship between motion and gravitation is not as straightforward as it might seem. In fact — and I'm glossing over this now, because the maths are damn complicated — whenever a gravitating object moves inertially, the gravitational acceleration vector at a point removed actually points at where the object actually is at a given instant, as opposed to where the object's light is seen to be coming from at that instant. So in that sense, we're back to gravitation being instantaneous again!
But is it really? No. Because you see, if the inertially moving object were to come to a stop instantaneously, the acceleration vector would continue to point toward its future position for a time, as if it were still moving inertially, even though the object is actually somewhere else. The sum of effects that serve to cancel out aberration when everything moves inertially would break down, and the acceleration field would point toward empty space for however long it takes for the change in geometry to propagate through space at the speed of light from the gravitating object to the point in question.
Except things don't stop moving instantaneously. Things accelerate, and acceleration requires energy, and when you factor that in, the equations balance out again.
(If you feel up to the challenging of following a lot of advanced mathematics, here's the best paper I know on the subject.) - http://arxiv.org/pdf/gr-qc/9909087v2.pdf
So what does that mean? It means that the "speed of gravity" is the speed of light … technically. Changes in the geometry of spacetime actually propagate at the speed of light, but the apparent effects of gravitation end up being instantaneous in all real-world dynamical systems, because things don't start or stop moving or gain or lose mass instantaneously for no reason. Once you factor in everything you need to in order to model a real system behaving in a realistic manner, you find that all the aberrations you might expect because of a finite speed of light end up canceling out, so gravity acts like it's instantaneous, even though the underlying phenomenon is most definitely not.
The universe is pretty damn cool, if you ask me.
When I want to ride, I take my fitbit out and put it into the velcro band and tie it around my ankle. It works surprisingly well, registering approximately each pedal stroke as a step. I register around 8,000 steps for a 15-mile bike ride. Since a 15 mile ride is a lot more exercise than 8,000 steps, I'll also mark in the app that I went cycling, and that's that.
I truly believe that TDD works. I truly believe that the jury is already in and that anyone who is serious about becoming a software professional should write tests for every line of code. I really really believe it and want to use it.
That being said, it is so fucking hard to get started with TDD. Oh god, it's so difficult. I've done the katas, done an apprenticeship, read the RSpec book, watched every screencast I could find, everything you can reasonably ask a learning developer to do, and I still find it incredibly impractical to practice TDD when working on most projects, not because I don't want to, but because it's so difficult and time consuming and the resources just aren't there to help make my process quicker.
Here's an idea for the TDD crowd. Every time you're about to write a blog post about why people should use TDD, instead write a blog post about a situation where you applied TDD, the tests you wrote and the code it lead to. We need more examples of TDD in progress, more code snippets, more screencasts. I'm telling you the problem is that the resources just aren't there to encourage these habits. Instead of continuing to have this debate at a semantic level, if there were more testing resources available I think people would naturally flock to it and TDD would win out. Until then, I think it's twitter fights and bad habits for the foreseeable future.
*This comment applies verbatim to security best practices as well.
In HAML all you have to do is this...
- @items.each do |item|
%fieldset{:data => {:id => item.id, :category => item.category}}
===In ERB the equivalent would be...
<% @items.each do |item| %>
<fieldset data-id="<%= item.id %>" data-category="<%= item.category %>">
</fieldset>
<% end %>===
It's a lot cleaner in HAML, especially extrapolated out over larger views.
Other than cool data visualization stuff, the obvious implication is the potential to devise a profitable system to pick games against the spread. The guys at Football Outsiders have done a decent job at it and made a proprietary algorithm that picked games at 58% this year ( which is over the threshold you need to be profitable in Vegas ). But even those guys are still having some trouble getting access to and aggregating the data in a usable format.
I really want to sit down and start playing around with some of this data so I appreciate you putting this together for everyone. The NFL needs an open source API and this is definitely a step in the right direction.