"Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd… I’ve learned that no toolchain can be too complicated because the drive for prestige and job security is too strong."
"Dumb robots, programmed to kill any broadcast containing copyrighted material, had destroyed the only live broadcast of the Hugo Awards."
thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.
"@Trackgirl was set up to infiltrate a group of runners. She would scour Twitter for messages with running-themed keywords and post them as if they were her own. Three times a day, she’d pick five people to follow, and she’d always follow back anybody who followed her. Because she seemed connected to the right people, @Trackgirl started to gain followers, who thought her cut-and-paste messages about the agony and the ecstasy of long-distance running were coming from a real person. One day, however, the Twitter bot posted a message saying that she’d hurt her ankle. Soon after, her followers wanted to know if @trackgirl was on the mend. “People were sympathizing with a Python script,” says Marra, a Google product manager who spoke about his work at the MIT-Knight Civic Media Conference in Boston last week."
A tale of two cities. Vulnerabilities of the London and Paris transit networks. →
Authors: C. von Ferber, B. Berche, T. Holovatch, Yu. Holovatch
This paper analyses the impact of random failure or attack on the public
transit networks of London and Paris in a comparative study. In particular we
analyze how the dysfunction or removal of sets of stations or links (rails,
roads, etc.) affects the connectivity properties within these networks. We show
how accumulating dysfunction leads to emergent phenomena that cause the
transportation system to break down as a whole. Simulating different directed
attack strategies, we find minimal strategies with high impact and identify
a-priory criteria that correlate with the resilience of these networks. To
demonstrate our approach, we choose the London and Paris public transit
networks. Our quantitative analysis is performed in the frames of the complex
network theory - a methodological tool that has emerged recently as an
interdisciplinary approach joining methods and concepts of the theory of random
graphs, percolation, and statistical physics. In conclusion we demonstrate that
taking into account cascading effects the network integrity is controlled for
both networks by less than 0.5 % of the stations i.e. 19 for Paris and 34 for
Today in transportation wonkery.
"Please don’t advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Instead, I humbly suggest that we spend our time learning how to …Research voraciously, and understand how the things around us work at a basic level.Communicate effectively with other human beings.These are skills that extend far beyond mere coding and will help you in every aspect of your life."
"from where non-techies stand, setting up a WordPress theme and coming up with Ruby on Rails from scratch have about the same degree of complexity.“Learning to code” doesn’t always mean becoming the next Linus Torvalds, just like “learning to cook” doesn’t mean opening a 3-stars restaurant.It simply means having a basic grasp of how computers work instead of blindly following whatever a talking paperclip tells you (and maybe eventually being able to program your own talking paperclips)."
"Business leaders don’t need to know how to code, but having an understanding of what is involved is always a good thing. This can help them avoid classic management mistakes like ‘doubling the number of programmers means something takes half as long’, as well as thinking that programmers can pull something magic out of their hats in no time at all (although this course in particular seems to do the exact opposite, and may do more harm than good)."
"one of the most tiresome things about working in the tech department of the Guardian is living with the knowledge that every single time we write an article designed to make the subject of programming accessible to a more mainstream audience, it is immediately followed by a rash of comments seemingly only designed to make the majority of the tech community look like smug know-it-all patronising killjoys. Why not just stay commenting on Slashdot and El Reg if that is all you are interested in doing?"