andreastt

This is a great question! I tend to find my debugging practice differs depending on the language I’m using and the array of problems, but the recurring common denominator is printf.

In Python I mostly rely on print(f) debugging, especially when working on multiprocessing programs, which I do rather frequently. With multiprocessed Python, pdb is useless. pdb is great, but not for a multi-process program. Most of my issues are related to sub-optimal API documentation that fails to point out argument types, and find I do a lot of trial-and-error programming, for which printf’s are great. Occasionally I drop into `import pdb; pdb.set_trace()` to inspect objects or the REPL to try out ideas.

JavaScript is an interesting beast where, next to console.log, I find myself using linters a great deal. A linter isn’t as sophisticated as compile-time checks, but does a frightfully good job at most trivial mistakes that are hard to debug in runtime. I often find myself running the linter under watch(1) so it updates when I make changes.

In Perl and shell, which I use ever more infrequently, the equivalent of the printf debugging is the norm. The only language I have found the debugger to be the first choice has been Java.

With Rust, I find myself resorting to a debugger surprisingly seldom. Its type system and the safety checks in the compiler catches most of the mistakes I make.

I don’t do much C programming anymore, but if I did, I would be interested in using rr (http://rr-project.org/), which allows you to record a run of the program and replay it _exactly_ as it was the first time, essentially letting you reproduce and fix race conditions.

96 HTTP requests, totaling 5406.72 KB, in 12.87 seconds. Maybe good design for print, but certainly not for web.

I wrote a little bit about this two years ago: https://sny.no/2014/04/dbts

There’s not necessarily an antagonism between distributed and centralised in this case. You can still have a centralised frontend such as Github Issues, backed by a versioned and distributed backend using i.e. git.

Isn’t it a little bit strange that the paper itself is writing about this, and presenting it as if it was a serious news story instead of a shameless plug for itself?

I can accept this for small, local papers, but this seems ludicrous.

And Twitter: https://twitter.com/htmlstandard

This is wonderful, not only because I can see my house on the screenshots, but because I’ve wondered about the exact same thing.

However, it turns out that my house is on the fake, tourist meridian line now. I can live with that. (-:

If a user has a sub-par experience browsing a website in one browser, she will switch to another and the loss is on the browser vendor’s behalf and not the website’s.

The vendor has an obligation to create the best web experience for the user and while it’s certainly a sad state of affairs that not more sites are testing for features rather than the UA string, it’s a sad fact that not all web authors care enough about interoperability to remedy their bad ways.

By far my favourite is

    alias sl ls

The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done.

Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was Mozilla's recommended workflow. Queues are a novel way to organise your work in progress, but is quite different from what people are used to coming from svn or git.

More recently bookmarks were added (also as an extension you have to opt-in to), which are reminiscent of git branches. They make it possible to have a HEAD-based workflow where you rebase frequently, much like you would with git, only that the defaults of `hg log` and various other commands don't interop very well, which means you have to memorise a lot of flags and arguments.

There are also many strange defaults in hg that you simply have to get used to, for example that `hg push` by default pushes everything. I have a hook in place on the remote end which prevents me from doing that.

By far the most frustrating experience with hg is that you cannot expect the default installation to come with sensible defaults. The argument is that keeping "advanced" functionality out of core prevents new users from accidentally using it.

An unintended consequence is that it sometimes makes it difficult for other people to help when you're stuck because more often than not their environment won't match yours.

One frequently lauded aspect of hg is that the user interface is easier to understand. Whilst I appreciate difference in taste, my experience is the opposite. If you follow the HEAD-based bookmark-style workflow, I find many cognitive dissonances in how the bookmark feature interacts with other commands.

At Mozilla we use hg for the canonical repositories and we have many Mozilla related extensions, but whereas I use hg every day now and it's a fine experience as long as I stay within the marked lines, I would return to git in a heartbeat if I had the chance.

It seems more similar in nature to Opera Turbo, which does a subset of the things described here.

Of course I'm being sarcastic. It's just very shoddy craftsmanship to launch a website for Chrome-only and leave it like that for several months.

For reference, this is being tracked by Mozilla's webcompat group in https://bugzilla.mozilla.org/show_bug.cgi?id=1131601.

I'm constantly bewildered by this notion that writing by hand is slow and thus bad, and that typing is fast and consequently good.

In my daily routine work as a programmer I find most of my work consists of thinking rather than writing. Or to twist the words a little: I don't think my typing impairs my creative ability, because the hard part of my job is thinking out the right solution. If you can't hold that thought in your head without typing the solution into your program quick enough to run and test it, perhaps you're not seeing patterns clearly.

As I work I constantly scribble notes on paper as I find it helps me think. When debugging a concrete problem, I find myself jotting down elements of the stack trace on paper so I can more easily retrace my steps. Concurrently I write down interesting things I come across that needs checking which I can return to when I'm done with my current line of thought.

Yet I'm fully aware I'm moving against the tide. I occasionally write longer pieces by hand several times a week, such as theories and findings. This helps me internalise patterns, solutions, and conclusions to interesting problems. Occasionally there are patterns and I can correlate good solutions to a problem to one I've solved in the past. But foremost it helps me _think_ better about the types of problems I'm trying to solve.

Programming is a creative discipline and not always about reapplying the same old patterns others have used before you. It's about craftsmanship and about learning the trade; about recognising those patterns and seeing new opportunity.

More to the point, my limitation isn't the speed at which I type things into my computer. The limitation is my brain not thinking fast enough.

Oh, my mistake entirely.

The correct link is https://blog.mozilla.org/blog/2014/11/19/promoting-choice-an.... Seems the link was changed.

This is great, but every time I read CSP as Communicating Sequential Processes. Funny thing about cultural contexts.

This is a problem in Chrome only. It renders fine in Firefox and Safari.

I'm quite surprised Hello World in C# could ever sound so lovely.

I recently relocated from Oslo to London. My living costs in London are higher than previously, mainly I think because housing standards are significantly lower in the UK. Certain things are cheaper in the UK, such as food, drink, and eating out. But housing prices are quite extreme.

It's licensed under SIL Open Font License 1.1:

https://github.com/mozilla/Fira/blob/master/LICENSE

There are a lot of hidden gems in the Naxos recordings, especially of rare composers and music but personally I find their quality subpar.

So Firefox does support multi-processed tabs through Electrolysis (its IPC layer). From what I understand this is used primarily on Firefox OS to sandbox app runtimes.

Doing one process per tab, which is what Chrome does, comes at a very steep cost in increased memory usage. If you compare a Chrome and Firefox instance holding 20 or 30 tabs, the memory consumption is going to be dramatically different.

Bill McCloskey did a nice writeup on this back in December: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-f...

His article explains how you can try out the experimental multi-process support in Firefox, but that it works differently to Chrome's. I think Chrome's way of doing it wastes a lot of system resources and that we need to be more clever about how we spend a user's system resources.

Happy 1 millionth bug!

He was an SVP of Engineering in between, I believe.

Why yes. My primary tool is the M1A1 Flamethrower. It does wonders for spreading my development philosophy which is my own variant of FDD; fear-driven development.

The easy solution is to set up an iptables route for disabling all non-loopback connections and traffic for port 57575.

I realize this is old, but I can't help but feel that comparing the personal homepages of the creators of two web frameworks and suggesting that the difference in design should have a say in which language it's best to pick borders on trolling…

At my previous employer, a small browser vendor that decided to abandon its own rendering engine and browser stack, I stopped using our product because Linux wasn't a priority. Numerous reasons were given, such as low market share, “only geeks use it”, all journalists use Macs, &c.

This was to the point of ridiculing the platform and the people working on it, frequently citing “Linux jokes” such as “you'll probably have to recompile your kernel first” whenever the question was seriously raised about when we'd start at least getting the core libraries working.

And when I say it wasn't a priority, I mean that we didn't even have something that was in a compilable state. A few people had started fixing up the broken code to get something that would compile on Linux in their own free time. After a few weeks of hacking, they were told by management to stop what they were doing and instead focus their volunteer efforts on the project goals, being to ship a Windows and Mac version.

So the company began the process of forcefully moving developers who'd worked on Linux for over 15 years to platforms they felt uncomfortable and unproductive working on.

This is a much longer tale, but it tells the story of a company alienating not only their loyal user base, but also a significant proportion of their own developers. The result? Lack of motivation and resignations.

Well done.

Ubuntu on workstation and laptop, Debian for everything else.

You can also look at their driver's license. That should tell you a thing or two about seniority.