ENTRIES TAGGED "debugging"

Four short links: 18 April 2014

Interview Tips, Data of Any Size, Science Writing, and Instrumented Javascript

1. 16 Interviewing Tips for User Studies — these apply to many situations beyond user interviews, too.
2. The Backlash Against Big Data contd. (Mike Loukides) — Learn to be a data skeptic. That doesn’t mean becoming skeptical about the value of data; it means asking the hard questions that anyone claiming to be a data scientist should ask. Think carefully about the questions you’re asking, the data you have to work with, and the results that you’re getting. And learn that data is about enabling intelligent discussions, not about turning a crank and having the right answer pop out.
3. The Science of Science Writing (American Scientist) — also applicable beyond the specific field for which it was written.
4. earhornEarhorn instruments your JavaScript and shows you a detailed, reversible, line-by-line log of JavaScript execution, sort of like console.log’s crazy uncle.
Comment

Debugging for beginners: a response

Practical strategies for debugging

This is a follow up to Brian MacDonald’s post on Debugging for Beginners. I read Brian’s post avidly, as I am always keen to take a look at different approaches to finding those elusive problems that plague all programmers (even those with decades of experience) from time to time.

Anyhow, I have to admit that I was a little bit…disappointed. You see, Brian writes in a wonderful, readable way, about topics that concern all programmers, whatever their background. But, I found that the general focus of his article was less on how to debug (even at a higher, theoretical level), and more about how to make fewer mistakes.

Comment: 1

Debugging for beginners

Nobody's perfect, and neither is your code, but that's OK

I discussed one thing that developers hate last time around — commenting — so I thought I’d follow up with another big source of developer frustration: Debugging.

Bugs happen. Every developer in the history of programming has had to debug, even the legendary ones who write code with butterflies. Becoming a skilled programmer doesn’t mean never making errors, it means becoming better at finding and fixing errors. When you’re starting out, your programs will likely be small enough that you may be able to figure out the problem by taking a closer look at your code, paying attention to the syntax, and tracing the execution process in your head. Once you get beyond that initial stage, though, you’ll need some help to find the bugs.

Comment

To IDE or Not to IDE?

Choosing the right tool for the beginning programmer

You’ve picked the language you want to learn, and you’ve learned more about the various language paradigms. You want to get started writing some actual code—but what tool do you use? With almost all languages, you can start writing code in any old text editor available to you, and that’s what programmers used to do, decades ago. Any good engineer, though, will find tools to make his or her job easier, and that’s where the Integrated Development Environment (IDE) comes into play. So now you need to learn how to use a tool before you can learn the language? Not necessarily. Although many programmers consider “should I use an IDE?” to be a question with an obvious answer, they don’t necessarily agree on what that answer is.

Four short links: 8 October 2013

Video Editing, Game Engine, Python Debugger, and P2P VPN

1. Lightworks — open source non-linear video editing software, with quite a history.
2. Puzzlescript — open source puzzle game engine for HTML5.
3. pudb — full-screen (text-mode) Python debugger.
4. Freelanfree, open-source, multi-platform, highly-configurable and peer-to-peer VPN software.

This Is My Brain on (Not) Programming

Taking a break from the return key and getting comfortable in the human world

Last week, I admitted that one of my key programming experiences had been with a typewriter. I wasn’t programming the typewriter: I just stopped programming. A few people liked this, others wondered about it, and (since it’s August) it seems worth explaining.

I started programming in seventh grade, on a ZX81. It took years for me to figure out what I was really doing. (In sixth grade, I’d bounced off a guide that showed A=A+1. I barely knew algebra, but I knew that was impossible.)

A few years later, I’d mostly mastered the many corners of Applesoft BASIC, memorized more of the Beagle Brothers chart than was wise, and done basic work with 6502 assembly. I knew how DOS 3.3 worked, how hi-res graphics was organized, and much more I don’t currently use. (I did get out of the house sometimes, though.)

After a summer program on media arts, I gave up programming. My spaghetti code had tied itself in knots around me, and I was especially tired of debugging. I kept finding myself switching from complex approaches I coded myself to simpler things I could make work through a GUI on an Amiga, and it felt like I’d hit a wall.

Comment: 1

Four short links: 1 April 2013

Machine Learning Demos, iOS Debugging, Industrial Internet, and Deanonymity

1. MLDemosan open-source visualization tool for machine learning algorithms created to help studying and understanding how several algorithms function and how their parameters affect and modify the results in problems of classification, regression, clustering, dimensionality reduction, dynamical systems and reward maximization. (via Mark Alen)
2. kiln (GitHub) — open source extensible on-device debugging framework for iOS apps.
3. Industrial Internet — the O’Reilly report on the industrial Internet of things is out. Prasad suggests an illustration: for every car with a rain sensor today, there are more than 10 that don’t have one. Instead of an optical sensor that turns on windshield wipers when it sees water, imagine the human in the car as a sensor — probably somewhat more discerning than the optical sensor in knowing what wiper setting is appropriate. A car could broadcast its wiper setting, along with its location, to the cloud. “Now you’ve got what you might call a rain API — two machines talking, mediated by a human being,” says Prasad. It could alert other cars to the presence of rain, perhaps switching on headlights automatically or changing the assumptions that nearby cars make about road traction.
4. Unique in the Crowd: The Privacy Bounds of Human Mobility (PDF, Nature) — We study fifteen months of human mobility data for one and a half million individuals and find that human mobility traces are highly unique. In fact, in a dataset where the location of an individual is specified hourly, and with a spatial resolution equal to that given by the carrier’s antennas, four spatio-temporal points are enough to uniquely identify 95% of the individuals. We coarsen the data spatially and temporally to find a formula for the uniqueness of human mobility traces given their resolution and the available outside information. This formula shows that the uniqueness of mobility traces decays approximately as the 1/10 power of their resolution. Hence, even coarse datasets provide little anonymity. These findings represent fundamental constraints to an individual’s privacy and have important implications for the design of frameworks and institutions dedicated to protect the privacy of individuals. As Edd observed, “You are a unique snowflake, after all.” (via Alasdair Allan)
Comment

Four short links: 15 June 2012

On Anonymous, Graph Database, Leap Second, and Debugging Creativity

1. In Flawed, Epic Anonymous Book, the Abyss Gazes Back (Wired) — Quinn Norton’s review of a book about Anonymous is an excellent introduction to Anonymous. Anonymous made us, its mediafags, masters of hedging language. The bombastic claims and hyperbolic declarations must be reported from their mouths, not from our publications. And yet still we make mistakes and publish lies and assumptions that slip through. There is some of this in all of journalism, but in a world where nothing is true and everything is permitted, it’s a constant existential slog. It’s why there’s not many of us on this beat.
2. Titan (GitHub) — Apache2-licensed distributed graph database optimized for storing and processing large-scale graphs within a multi-machine cluster. Cassandra and HBase backends, implements the Blueprints graph API. (via Hacker News)
3. Extra Second This June — we’re getting a leap second this year: there’ll be 2012 June 30, 23h 59m 60s. Calendars are fun.
4. On Creativity (Beta Knowledge) — I wanted to create a game where even the developers couldn’t see what was coming. Of course I wasn’t thinking about debugging at this point. The people who did the debugging asked me what was a bug. I could not answer that. — Keita Takahashi, game designer (Katamari Damacy, Noby Noby Boy). Awesome quote.
Comment: 1

Four short links: 18 February 2010

1. David Cameron, The Next Age of Government (TED Talk) — Cameron’s argument is that with open data and behavioural economics, we can offer policy preferences but let people make informed choices. Interesting that transparency and open data can be a bipartisan issue.
2. Finding Ada — pledge to blog about an inspirational woman in technology or science on March 24. I like it because it turns up personal stories and interesting people that I’d otherwise never have heard of.
3. On MicroSD Problems (Bunnie Huang) — fascinating detective story as he tries to figure out how he got some dud Kingston SD cards. SPOILER ALERT: fault-tolerant hardware gets sold in tranches (great, ok, bad) and the bad tranche sold off-label.
4. A new global visual language for the BBC’s digital services — an amazingly detailed guide to the rationale and structure of the BBC web redesign. It’s not often that you get this much detail into someone else’s design, which is a shame because it’s very instructive to read.