That's what I thought too, at first glance. Didn't know the other 'Slack' yet.

Bandwidth isn't expensive, but getting it to some location where you actually want to use it, is.

Of course, high-bandwidth connections are cheap at an IX, but the cost of sufficient real estate inside that IX to live comfortably close to your cheap bandwidth won't make your total cost of living look pretty.

On a side note: you may have a nice fiber with 100Gbps capability. What do you think the hardware costs that can actually handle that link?

More numbers are also not necessarily more accurate either... In our measuring course at university, we got that explained very thoroughly: we got shown a pretty nice (digital) handheld Fluke and a huge, antique analog AVO meter. Both meters were regularly checked and calibrated in-house. Of course everyone was convinced the Fluke would be much more accurate because it was easily 20 years younger.

Then we had to do the actual calculations, based on the accuracy given on the case of the meters. Surprise: the analog meter was still more than twice as accurate as the digital one (if you can read it correctly, of course.) When actually checking the information, it turned out that the last digit on the digital meter was pretty useless because the measurement error was a very significant fraction of that digit.

These were devices used in Electrical Engineering, where it's actually important to know how valid the information is that you read off your meters. ... and an anecdote about digital-analog meters in cars: a couple of years ago I got into a strange situation where the gauges system of my dash didn't boot. Everything worked: indicator lights, odometer, engine was running, but all analog meters remained at zero. I could run the car by the engine sound until I could pull over and restart, but it still felt weird every time I glanced at the dash.

Not anymore, at least not in Belgium. The doctor peels the label off the exact shot you got and puts it into the book. After the fourth shot (around 14 months), they fill out a form that you then have to return to the municipality to prove that your kid had their basic Polio vaccinations (there's one more around 6 yrs), which ones and when, so there are at least three separate registrations.

Polio is the only mandatory vaccination in Belgium and they take it fairly seriously. Personally, we take all vaccinations seriously, especially for our kids, but that's mostly because we sometimes hang out with alternative types (Waldorf education tends to also be pretty anti-vax; they are actually the biggest risk of non-vaccination here) and reformed Christians, so we are not counting on herd immunity there...

I will keep an eye on this, though...

As this particular thread is off-topic anyway: Thanks for your blog, Mr. Bolton! It's always an interesting read and I try to point new testers to it at least once to get some exposure to a usually unknown view on testing.

No, you tell them that you appreciate the effort they took to look good, you don't tell them they're beautiful or handsome. This is by the exact same reasoning: should they get badly hurt in an accident, you'll also have given them psychological issues because they'll have lost a part of themselves (and some people don't have many other parts of themselves to fall back on, while everyone can work hard to improve.)

You don't praise your kids for things that are part of who they are, you praise them for the efforts they make.

Same here. As far as I've always assumed, that issue seems to be because your eyes 'white-balance' separately. If you close one eye in sunlight, your closed eye will be blue-shifted after a while because while your eyelid is closed, it sees only red light which your brain tries to compensate to the same color your other eye is seeing. When I was young, I sometimes sat with both eyes closed outside, in full sunlight; if I went inside the house immediately after I opened my eyes, the entire interior of the house would be blue for a while.

If my head is turned to one side in bed, I tend to have my lowermost eye closed more than my uppermost eye, leading to the same effect.

... it's useful _to have a clamp-style multimeter_ to check the load on ...

I haven't slept enough.

For the multimeter: if you'll have anything to do with power, it's useful if you can check the load on a rack or phase without having to call the electricians (if some part of your power infrastructure is overloaded and your fuses keep tripping, you can quickly rebalance the load until an electrician can have a detailed look.)

That's not entirely true. The bonding happens for a big part through skin-on-skin contact, which releases hormones. Even though you can still do that if you aren't the natural mother, it's much harder than when you get that endorphin/oxytocin/prolactin boost during pregnancy, birth and breastfeeding. Most modern advice even explicitly encourages the father to hold the baby for a couple of hours, skin-on-skin, some time after birth while the mother is being cleaned up and/or asleep. With a C-section the mother isn't available to hold the baby at all during the first hours; the advice then is to get the father half naked and get him to hold the baby during that time.

Of course I agree with you that fathers and adopting parents do bond with their children through anticipation, preparation and shared experiences, but this is definitely not the main process that normally takes place and I don't think it should be the only one if it can be avoided.

I'd like to chip in with my view as a fairly recent daddy too, as we probably don't live too far apart (your username puts you in Flanders or southern Netherlands, but giving birth in hospital is very uncommon in NL nowadays, so my guess is Belgium.)

Judging from many stories (that everyone suddenly has when you are expecting a baby), Flemish hospitals, even the good ones, are not to be considered the gold standard for giving birth. In most places the doctor and hospital staff decide what's going to happen, preferring to force their way for convenience (theirs) or just because Procedures Must Be Followed rather than actual care for what's happening. We did extensive research, even before conception, on where we wanted our baby to be born and quickly chose a hospital well over an hour away because they are the maternity specialists of the province (every province has one) -- there are hospitals closer by, but just looking at their maternity ward websites was enough to reject them outright (the gynecologist decides this, this is the schedule of the maternity ward, we decide that...)

Eventually we didn't even make it there because everything just happened too fast, our baby was born at home with the help of independent midwives (don't go without professional help, there are still some risks), and I was surprised at how easy it went (of course, it's still a bit messy, it's still painful, there's still some screaming, but afterwards our midwives also told us that home birthings are always much easier, cleaner and less painful than in a hospital. ) No epidural, no inducing, no vacuum extraction, no episiotomy (because no tearing); I'm not saying that these techniques should never be used, but they are definitely overused in Flemish hospitals, sometimes to the point of normal operating procedure for _all_ births. I'm also not advocating home birthing for everyone: some parts are easier, but especially the fact that you are immediately thrown back onto yourselves after birth was very hard for us (we had household help and of course the midwives come to check up regularly for a couple of weeks, but they also have to tend to other expectant mothers, mothers and babies in a fairly large region, so you don't have someone at your bedside five minutes after you push a button, it's just the two of you.. if there are two of you, which isn't as standard as it used to be.) I just wanted to make clear that Flemish hospitals are not really the desirable solution when it comes to giving birth.

As for the original issue: I indeed see serious issues with artificial wombs. When a baby is growing, is causes a lot of violent hormonal changes within its mother. Of course this causes a lot of issues and inconveniences, but it also creates a very strong hormonal bond between mother and child. It's not just something you ordered on a website somewhere with the prime advantage of being able to watch the production process. A baby actually grows inside of you, you feel it as it starts moving around, it takes much effort to 'produce' a baby long before you see the results, which is getting less and less acceptable in modern societies. This experience of long-term effort is important for the future of the baby, because it's something that won't stop for quite some years.

Another issue my wife just pointed out to me: the number of kids from an artificial womb diagnosed with autism will probably also be much higher than average. A baby doesn't start living the moment it's born, it's already experiencing and learning a lot from the outside world long before (street noises, music, arguments, stepping around, lying still, ...) It will not have those experiences in an artificial womb, so it will be less prepared for what will happen when it's born.

Yup, that's a good list... some more things:

  - I assume GP meant a test plan instead of a test script: a test script is closer to automating (push button x, check value y, ...); a test plan describes what you are going to test, what you have tested and what the results were, usually starting as a very rough overview of the feature, how it works, which area should be tested in which way, which sources you used to determine what counts as 'correct behavior'... As you work on the feature, you start refining the test plan, adding tests for issues you didn't think about before, areas that turned out to be involved which you initially didn't see, dropping tests that turned out to be unnecessary, ...
  - Investigating (buying of/errors with) test tools (in my field you need some pretty high-end devices to be able to simulate large customer environments and a lot of these devices tend to be limited or broken in very unexpected ways.)
  - Testing whether the product will hold under repetitive use (endurance)
  - Testing whether the product will hold under high stress (scaling/performance)
  - Testing whether the product works well within the environment for which it is intended (lots of software needs to interact with other hardware or software, but you usually don't have control over those other products)
  - Testing whether the product is internally consistent and if your feature works well with other features in the same product (on a large project, this aspect of testing tends to explode as the number of features increases. That is when you'll need your testing and product experience to quickly filter out the risky combinations.) If the product is intended to be upgradeable: testing whether for instance data files stay usable between versions.
  - For highly available products: check that all aspects of your feature keep working if it has to switch to the backup system
  - Testing whether the product is secure
  - Discussing (I wouldn't call it arguing) with developers and product management whether issues you found are actually bugs and if the feature as designed (or sometimes even as requested!) will even solve the customer's problem. (You can make a perfectly functioning screwdriver in request for a 'device for mounting fastening materials), but if the customer was looking for something to drive in a nail, chances are it won't sell to that customer.)
  - Regularly checking the results of you automated tests and seeing if a failure is due to an intended software change or if it's a regression bug.
  - Senior testers where I work are also regularly involved in feature design together with product management and development.
  - Pushing the product to its limits (memory exhaustion handling, starvation from lack of other resources, timing issues, ...) and checking that resources are properly freed (nowadays the runtime environment usually takes care of this, but not always; some products still need very low-level coding where you cannot spare the cycles to do those tests at runtime.)
  - Working with high-level support to determine the cause of issues coming in from the field. If you have a good support group, whatever comes to the highest level there is something that needs test and development expertise to get solved. (Our highest level of support actually mostly consists of former test engineers.)

In response to the black/grey/white box testing (I actually prefer 'transparent' instead of white; a white box is still opaque): you'll usually work somewhere in between, starting from black box and going deeper if you get a bad feeling about the code you are testing (or if you need to give the developer a very detailed report about what's going wrong.) Full transparent-box testing is more akin to unit testing, which is the developer's responsibility (at least where I work).

If you are at odds with developers over the issues you find, something is wrong, at least when it goes beyond some friendly rivalry between test and development. Test and development are not enemies, they are both working together towards the same goal: a good product that the customer likes to use. In any non-trivial project, the developers *will* make mistakes, that's unavoidable. The testers will also make mistakes and flag issues that aren't really bugs... we are working on the same floor as development and when we find an issue that we can't immediately determine the cause of, we try to find as much information as possible and then ask the developers for help. We (the testers) know what we see, but the developers know exactly how the code works and what causes what we see.

More importantly: writing the test script yourself and not letting other (mostly non-testers) do it for you. If you have nothing to say about what will be tested and how, you won't be able to test thoroughly. If they won't let you write your own test script, you won't be a tester, you'll be a real QA Scapeg-erm-Engineer: you'll just be there to assure that there is 'quality' (What _is_ quality, actually?) and have your ass on the line if it turns out there isn't because your job description says _you_ assure everyone there is. You cannot guarantee perfection as a tester -- you don't have full freedom to change shipping schedules and you're not allowed to change the code -- so you cannot assure quality. You can at most provide valuable advice about the state of the product to the people that can make those decisions: that's the difference between a QA Engineer and a Tester.

Effectively you are also testing your own test script... Where is it incomplete? Did you miss requirements (it's not just your product requirements documentation that provides the requirements, you also have standards, user expectations, laws and many other sources that are typically not referenced in product requirements but are vital to making a good product.)

If you even need to test something more than once, do it the lazy sysadmin way: automate it. If you are expected to test multiple releases of the same program: prepare to spend at least 50% of your time automating (I usually start from automation, which has the added advantage that over time you build a library to quickly set up large parts of test scenarios, even for manual testing if you interrupt your automation scripts in the right spot.)

For much more information and better explanations, my advice would be to check the blog of Michael Bolton (http://www.developsense.com/blog/), who links to other great software testing minds that use the same ideas like Cem Kaner, James Bach etc... (I usually read Michaels blog though, mostly because I like his writing style.) They definitely brought more fun and insights into my testing work.

At least for Antwerp, yes. (Although the premetro is not technically a subway, it's a tramway that's been put underground in the city center; it has overhead power instead of a 3rd rail.) The power sections run from station to station (the connection diagrams are on the emergency separator switches in the stations so you know if it switches the section before or after the current station.)

The things you pay attention to as a geek.