Sunday, June 28, 2009

The poor doctors want to be able to proselytize

Via several of my facebook friend, I read this BBC article

Doctors want right to talk faith

Doctors are demanding that NHS staff be given a right to discuss spiritual issues with patients as well as being allowed to offer to pray for them.

Medics will tell the British Medical Association conference this week that staff should not be disciplined as long as they handle the issue sensitively.

The people in question might call it "talk faith", I call it proselytizing, and I find it entirely wrong for any medical personnel to be involved in that - no matter the faith in question (I would also find it wrong for an atheist to try to deconvert people in hospitals).

There are several reasons for why it's wrong, but the one most people should be able to understand, is the fact that the patients are a captured audience, who can't just get up and leave. They should also feel comfortable with the medical personnel they come into contact with, and if said personnel tried to proselytize in any way or form, it would make a great number of the patients feel uncomfortable.

I really can't see why this should be so hard to understand.

And to make it even worse: as the article makes clear, there are even dedicated personnel to cater to peoples' religious needs.

However, the Department of Health said it was the responsibility of the NHS Chaplaincy Service to meet the spiritual needs of patients.

A spokeswoman said: "We are committed to the principle of ensuring that patients and staff in the NHS have access to the spiritual care that they want, whatever faith or belief system they follow.

"Although all staff should be sensitive to religious needs and preferences of patients, the delivery of spiritual care should be provided by the hospital chaplaincy service."

Still, some of the people interviewed in the article doesn't get it.

But Joyce Robins, co-director of Patient Concern said: "Most complaints from patients are about being on a conveyor belt of care. They don't rate with staff as real people.

"Offering to say a prayer is a warm and kind thought. Most patients will accept it as such. It is no more offensive than being offered a sleeping pill. You can say thanks but that sort of thing isn't my cup of tea.

As an atheist, I would kindly ask the doctor, nurse, or whatever to bugger off and never bother me again. I would also complain to the hospital, and ask them to ensure that said person had nothing to do with me in any way or form again. It's not only because I would find it offensive, which I would, but also because I would find it disturbing and profoundly unprofessional. I would, in other words, loose my trust in said person.

Still, my reaction would be mild compared to the reaction of e.g. a Muslim, Jew, or Hindu person, if a Christian person offered to say a prayer for them (and vice versa). To many of those people, it would be an insult of the greatest degree.

For a person like Joyce Robins to not understand this shows how sheltered from other cultures she has been.

It's really not a question about freedom of religion, but a question of being a professional. As someone employed as a medical personnel you are entitled to your religious beliefs, but you are not entitled to push them on other, while acting in an official capacity. What you do outside your workplace, is your own business (with certain legal limits of course).

Labels: , , , ,


Via feministe, I came across this interesting article in a Swedish newspaper.

Swedish parents keep 2-year-old's gender secret

A couple of Swedish parents have stirred up debate in the country by refusing to reveal whether their two-and-a-half-year-old child is a boy or a girl.

Pop’s parents [see footnote], both 24, made a decision when their baby was born to keep Pop’s sex a secret. Aside from a select few – those who have changed the child’s diaper – nobody knows Pop’s gender; if anyone enquires, Pop’s parents simply say they don’t disclose this information.

In an interview with newspaper Svenska Dagbladet in March, the parents were quoted saying their decision was rooted in the feminist philosophy that gender is a social construction.

Interestingly enough, I've been working in Malmö in Southern Sweden for the last couple of months (it's withing traveling distance of Copenhagen), and while different news items were brought up from time to time, none of my Swedish co-workers mentioned this particular piece of news. Maybe it's not the sort of news appealing to Swedish computer programmers?

Anyway, I found the article very interesting, and the motivation behind it even more so. If this experiment turns out successfully, it will add greatly to our knowledge about how the social constructs of gender affects children when growing up.

Of course, reading the comments on the article, both beneath the article and elsewhere, shows that a lot of people have a hard time understanding the concept of gender as a social construct and keep mixing it with biological aspects of genders.

There are really at least two aspects of genders, which forms genders as a whole.

  • The biological aspect. Here we are talking about biological things like sexual organs, muscle mass etc.

  • The socio-cultural aspect. This is the socio-cultural norms forming the behavior of people belonging to the different genders.

We don't know where the exact line between these two aspects can be drawn (if at all). E.g. some people claim that differences in mathematical ability between the genders is a biological aspect, while others (myself very much included) thinks it's the result of a socia-cultural bias.

What Pop's parents are doing, is to try removing the limitations which the socio-cultural biases will place on Pop, by ensuring that these biases are not part of Pop's early upbringing. Hopefully, this will allow Pop freedom to choose the paths Pop wants, without a socio-cultural ballast dragging Pop down one path or another.

Of course, this experiment is not without problems. When Pop grows older, and fails to adhere to the socio-cultural norms of Pop's gender, there could be a social stigma involved. Since Sweden is quite a progressive country, this will hopefully not be too bad a problem, but it's a risk.

Edit: I've had to close comments on this post, as it attracts a lot of Asian spam.

Labels: ,

Sunday, June 21, 2009

Lazy linking and carnivals

A few links which I thought might interest people.

National Geographic has an interesting article on Angkor

The 113th Skeptics' Circle is up at the The Unincredible Hallq.

Scientia Pro Publica 6 is up at Mauka to Makai.

PZ Myers have been busy writing about science lately, and have posted three great science posts this week. Big love among the ostracodsBig love among the ostracods, Limusaurus inextricabilis, and Digit numbering and limb development.

Over at Orcinus, Sara has written a great post Mythbusting Right-Wing Domestic Terrorism

The Feminist eZine -
1001 Feminist Links and Other Interesting Topics

The Good (but endangered) Samaritans

Labels: , , ,

Monday, June 15, 2009

Neo-Nazis in the US military. Why isn't this getting more coverage?

I note with approval that Salon has a front page article on the spread of Neo-Nazis in the military.

Neo-Nazis are in the Army now

Why the U.S. military is ignoring its own regulations and permitting white supremacists to join its ranks.

I am happy that Salon has written this article on an issue which should worry everyone, considering recent events such as the murder of Dr. Tiller and the shooting at the Holocaust museum. The problem is of course that this is not exactly news. Back in 2006, the Intelligence Report, published by Southern Poverty Law Center, wrote about this very issue. See:

A Few Bad Men
Ten years after a scandal over neo-Nazis in the armed forces, extremists are once again worming their way into a recruit-starved military.

Extremism and the Military
Racist Extremists Active in U.S. Military
Pentagon in Denial About Racist Extremists in Ranks

They followed up on the issue, with articles such as 'Killing a Brown' - New Evidence of Extremists in the Military (winter 2008), which David Neiwert commented on.

None of this made the news media in any notable way.

And then, there was FBI's (in)famous report White Supremacist Recruitment of Military Personnel since 9/11 (.pdf), which was covered by the media, but where the coverage was drowned out by the widespread denouncements of the report made by Republicans and right-wing pundits.

So, what does it take for this to make the main-stream media? Why aren't they following up on these things? Currently there is a very worrisome uptick in US domestic terrorism, often perpetrated by people with ties to the far-right. Shouldn't this worry the media a lot more than it apparently does?

I hope that Intelligence Rapport and Salon keep up the good work. No one else seems to be willing to do it.

Labels: , , , , ,

I've created a new blog

Looking back at my, rather long, blog post on testing in systems development, I found that that sort of post didn't quite fit in at this blog, so I took the consequences and started a new blog for that sort of long, rather narrow posts on systems development, programming, and IT consulting.

It's named Ending Error-driven Development, and if you want to read it through a feedreader, you'll find its feed here.

Given the fact that the majority of my blog writing centers on other issues, the blogging over at the new blog will be even lighter than at this blog.

Labels: ,

Saturday, June 13, 2009

Avoiding error-driven development, part 1 - testing

Some time ago, I wrote about something I call ”error-driven development”, which is a type of software development I come across all too often. You can find the original post here.

I’ve found out that many software developers and consultants can relate to the post, and I’ve discussed with several what one can do about error-driven development (EDD).

Well, there is no perfect answer to this question, since the root cause of EDD is different in every EDD project. I have, however, been on a number of EDD projects through the years, so I have some suggestion on some general measures one can do to either turn EDD into something else, or to limit the damage.

I’ll try to go through some of them from time to time. In this post I’ll focus on testing.


I will make the claim that testing is one of the most underrated activities in software development projects, and this has to change in order to avoid EDD. What’s more, testing is also a widely misunderstood concept. Testing is a much bigger activity than most people believe, and covers more aspects than generally thought.

Testing should of course ensure that the system works as intended, but it should also ensure that the system doesn’t work when it’s not supposed to, and that the system can handle unexpected events in a meaningful way.

In his book, Release It, Michael Nygard makes a very good point: Systems are built to pass acceptances tests, not to run in the real world. This is one of the things that lead to EDD projects, where the developers are working on a later version of a system which is in production.

Testing should allow for the particularities of the real world, and not only for the test environments (see Release It for some very good examples of the differences, and some good ways of making up for these differences).

There are several types of testing, some of which I will cover here, and in my experience, focusing on just one of them, will lead to problems in the long run.


With the spreading of concepts like test-driven development, unittests are very much in the vogue. Unfortunately, books on TDD and its irk generally doesn’t explain how unittests should be written – just that the they are important, and should be written before the code.

Making unittests ensuring that code works as expected is of course very important, but if that’s all what the unittests do, it’s not enough. Unittests should also ensure that code doesn’t work when that’s expected – e.g. if a method gets an invalid parameter, you expect it to fail in some way or another. Tests for this – don’t just assume that this is the case, even if the code works with correct input parameters. Besides ensuring that the code works as it should, even when this means throwing an exception, it also makes it easier for others to see what behavior is expected of the code.

There is, unfortunately, a tendency to focus on code coverage of unittests, where code coverage is taken to mean percentage of code lines executed during the tests. This is the wrong code coverage measure. Instead one should focus on covering all the breaking and non-breaking states that the code can be in.

E.g. if you have some code which receives a text string containing a number, which it converts to a number, make sure to test the following:
a) A string containing a positive integer
b) A string containing a positive floating point number using the normal separator (in the US an example could be “10.10”)
c) A string containing a positive floating point number using a separator from a different culture (e.g. the Danish “10,10”).
d) The same as b) and c) just with thousand-separators (“1,000.00” and “1.000,00” respectively).
e) The same as a) through d), but with negative numbers instead.
f) A string containing a number too large to be handled by the data type it’s going to be converted to.
g) A string containing a negative number too large to be handled by the data type it’s going to be converted to.
h) A string containing letters
i) A string containing zeros in front of the number

I could continue, but you get the point. As you can see, that’s a large number of tests for a fairly simple functionality, which is often implemented by using built in functionality. Even so, it’s worth spending the time on doing these, as this is the sort of things which can cause real problems in production.

Smoke testing

Unittests are of course not the only sort of testing; there are others which are just as important. Smoke tests are automatic tests which can be run to test different flows through the system. E.g. in an internet portal, the smoke test might log in, and navigate to a specific page, while entering data in the intermediate pages.

These tests generally need some kind of tool to be made. Depending on your development framework and the nature of the system, you need to find one that suits you. In portal projects I’ve seen pretty good results with smoke tests made in Ruby, but in my current project, we are using Art of Test’s WebAii, where the tests are written in C# or VB.NET (but can test web GUIs written in other languages).

Smoke tests require a lot of time to make and maintain, especially in a system where the user interface is changed often. In such cases, it might make sense to have resources focused on running and maintaining smoke tests. These shouldn’t only focus on this, but they should have the responsibility to ensure that all smoke tests can run at all time.

Even if there are people responsible for maintaining it should be the responsibility of the developers to run the relevant smoke tests before checking in any changes to the user interface, and in case it fails, to correct the tests or the code as needs be.

Smoke tests help ensure that changes in one part of the user interface don’t have a negative impact on the functionality of another part, which is often the case.

Integration testing

In these days of SOA, ROA and what have you, it’s very rare that a system stands alone. Rather, systems tend to work together with other systems through integration points. Even the system doesn’t work with other systems over the network, it will generally use a database manage system, such as DB2, Oracle, or MS SQL, run in an operative systems (*NIX, Windows etc.), or have other interaction with other systems. All this should be tested.

If possible, integration testing should be automated, but even if that’s not practical for some reason or other, manual integration testing should be done.

As in smoke testing, it’s possible to get a number of tools which allows you to make the tests. The selection of tools again depends on the system and the development framework.

Integration testing can be very difficult, as the testing is dependent upon external systems, some of which might not have been coded yet. In such cases, remember that it’s not the other systems that the test should test, but rather the integration points with these. So, there is no real need for a fully functional system in the other end. Rather, it’s sufficient to have a mock system which sends data as it could appear from the external system. This can be done through tools like soapUI, which can both send data through webservices your system exposes, and which can serve as a receiver for your web service requests. Of course, this isn’t always enough, and I have experienced a project where the behavior of the developed system was so dependent on the retrieved data, that it was necessary to build a simulator, simulating all the back end systems.

Remember to test for differences in cultures in different systems. Can your system survive that the date-format or numbers it receives confirm to a different cultural standard than yours? This is something that’s easily overlooked, but which can have a great impact – either by crashing the system, or by the system misunderstanding the values. It makes a great difference if the date “1/5/2009” is January 5th or May 1st.

Even less ambiguous formats might cause problems, and they can be even harder to figure out. E.g. if you use a date format “dd-MMM-yyyy”, would be fine for the first 4 months when exchanging data between a Danish and a US system, but on May 1st it would be “01-May-2009” in the English speaking world, but “01-Maj-2009” in the Danish speaking world. This could mean that the system suddenly, and unexpectedly, stops working as expected, even though everything has been running just fine until then (this is not an made up example – I once started in a new job on May 1st, where my first accomplishment was to figure out this exact problem).

The more integration tests you make during development, the fewer fixes needs to be done when the system is in production (I refer to Michael Nygard's Release It for good advice on making testing environments for integration testing).

Manual testing

There is unfortunately a tendency for developers to believe that as long as you have enough automatic tests, there is no need for manual testing. This is of course nonsense.
No matter how many automatic tests you have, and how sophisticated tools you’ve used to make them, there is no substitute for human eyes on the system.

Manuel tests can be divided into two groups: Systematic testing (based on test cases) and monkey testing.

Systematic testing, normally done based on test cases, tests the functionality of the system, ensuring that it works as specified, including implicit specifications. The testers should have enough understanding of the business that they meaningfully test the system, not just follow the test script step-by-step.

With regards to the test cases, my general suggestion is that they are not written by technical people, but rather by people with an understanding of the business domain. Optimally they should be written at the same time as the requirements or at least before the coding really start, and only be in general terms. Before the developer starts developing, he or she should read the relevant test cases, making sure that he or she understands the requirements as stated in general terms. If there are some business concepts that appear unclear, it’s possible for the developer to acquire the necessary domain knowledge before starting on the development. When the system is developed, the test cases can be made specific to the system (I recommend keeping the unspecific test cases in reserve though, as the system can change a lot over the time, and it’s good to have some general test cases to refer back to).

As with all the earlier tests, there should also be testing of wrong usage of the system, ensuring that this wrong usage will result in neither major problems nor a wrong result.

Note that while test cases and use cases might sound similar, at least at first, as I describe test cases, that’s not really the case. Use cases describe things on an abstract level, while test cases are more specific. In an insurance system, a use case would describe how the user creates an insurance policy. Test cases would not only describe that the user will create an insurance policy, but rather what sort of insurance to choose, what values should be used, and what extras should be selected.

Monkey testing is unsophisticated testing of the system, where the tester tries to do whatever suits him or her, trying to provoke a failure in the system. It might be entering a wrong value in a field, clicking on a button several times in a row, or doing something else unexpected by the developers. The purpose of the testing is to emulate the sort of things which might happen in the real world, outside the safe testing zone.

While monkey testing it’s very important to document the exact steps which results in the error. Some times the symptom of the error (the system failing) occurs a rather long time after the action which caused the error.

In conclusion

There are of course many other sorts of testing (performance testing for one), but I feel that by doing the sort of testing I mention, one can do a lot to prevent a project turning into an EDD project.

The reason good testing can help avoid EDD is simple. A lot of the time EDD projects only addresses the symptoms, fixing bugs as they are reported, but they don’t address the fundamental problems, so these fixes are only temporary at best, and in general introduces other errors, which are only discovered at a later stage.

Testing will ensure that the system being developed is stable, or at least that the non-working functionality are discovered at an earlier stage. Testing also ensures that changes can be introduced more easily, as side-effects are shown straight away.

Of course, introducing testing into an EDD project is not easy. It will be running behind schedule, and people will be overburdened with work, so adding new tasks will not be doable. This doesn’t mean that testing shouldn’t be done though, just that it should be done in steps, rather than all at once. Find the core functionality, or alternatively the most problematic code, and introduce testing there – unittesting should come first, but don’t forget the other types of testing.

I know this is easier said than done, but I’ve been in projects solidly in the EDD category, which we managed to turn around, in part because of testing. In one project, we made the case for unittests by making 10 unittests of basic functionality in the system, showing eight of them failing. This resulted in me getting resources allocated to me, just to ensure proper unittesting of all basic functionality (we later expanded to other functionality and introduced other types of testing).

If such a drastic demonstration isn’t possible, start by doing unittests whenever you change some code – this will ensure that the code works properly after you’ve changed it. Sadly, code in EDD projects are often not in a stage where unittests can easily be introduced. This is why they should be introduced when the code is changed anyway, since it gives an opportunity for refactoring the code at hand to allow unittests.

I hope this rather long post made sense to people. It’s not revolutionary concepts I’m trying to introduce, and for many people, the things I mention are blatantly obvious. Even so, there are many people, and organizations, out there, for which testing doesn’t come naturally. These people, and organizations, need to be reminded ever so often that there is a very good reason why we do these things.

Testing can’t stand alone of course; many other measures are needed to avoid project development to turn into EDD, or to turn a project away from being an EDD project. Still, they are fundamental for a healthy development, so leaving them out, will more or less guarantee that the project turn into EDD.

Labels: , , ,

Friday, June 05, 2009

Voting dilemma

In Europe, the voting for the EU parliament is currently going on, and in Denmark it happens on Sunday. At the same time, Danish voters are also asked to vote on a change of the constitution, which would change the rules regarding succession in the Royal family.

Currently the rules are that if the current monarch has one or more sons, the oldest son is the successor. In case there are no sons, the oldest daughter is the successor (in case there are no children, it gets more complicated).

The constitution change would result in men and women being treated equal, so it's always the eldest child, no matter their gender.

As a progressive, I have some serious problems deciding what to vote. Since I am very much for equal rights, I won't vote against, but I am debating whether I should vote at all. I regard the whole concept of royalty as outdated and abhorrent - the whole concept that someone gain privileges according to the law, solely because of their family ties, goes against everything I consider important. Voting yes to the constitution change could be seem to legitimize the whole system of royalty.

I know I am not alone in thinking this in Denmark, and many non-royalists are considering not voting, turning it into a referendum on royalty. If less than 40% of the eligible voters vote yes, the change will fail, regardless of the result.

Labels: , ,

Tuesday, June 02, 2009

Olbermann on O'Reilly's role in Dr. Tiller's murder

Keith Olbermann is often wrong, some times hugely so, but when he is right, boy, he is right.

Bill O'Reilly is as guilty as Operation Rescue - he, and his ilk, have been busy pushing the extremist views of groups like Operation Rescue to the mainstream, creating an environment where the murder of Dr. Tiller could happen. Well, it's time that he learns that words have consequences.

Labels: , , ,

Monday, June 01, 2009

Silent no more

Yesterday night, as my tongue started to swell up because of my allergic reaction to something I had eaten, I went to an emergency room in a nearby hospital. It was a quiet night, and there was only one other person in front of me - a 19 year old girl acting really strangely, together with two older women. It turned out that her drink had been spiked with something, and she was now in some kind of narcotic haze.

It was a quite frightening thing to see, and it's obvious what the intend had been of the person who had spiked the drink. Luckily she sensed that something was wrong with her, and got to a hospital before anything happened to her.

For many woman out there, that's not an option. In large areas of the world, women are routinely raped, while the whole world is silent. This silence allows the atrocities to continue. This is why there is a new initiative to end the silence.

Sheril Kirshenbaum has explained it in her blogpost Silence Is The Enemy

Today begins a very important initiative called Silence Is The Enemy to help a generation of young women half a world away.Why? Because they are our sisters and children–the victims of sexual abuse who don’t have the means to ask for help. We have power in our words and influence. Along with our audience, we’re able to speak for them. I’m asking all of you–bloggers, writers, teachers, and concerned citizens–to use whatever platform you have to call for an end to the rape and abuse of women and girls in Liberia and around the world.

As I wrote yesterday evening, through the fury I felt at Dr. Tiller's death, Words Have Consequences. But so does the lack of words and actions. Not speaking up when other people are raped allows others to keep raping, not defending someone when they are in danger of rape, allows them to get raped. This is why we should all speak out against rape - to not do so, is to allow rape to continue.

Words, however, is not enough - action is also required. It might seem impossible to do something when you're an individual living far from where the atrocities that Sheril describes in her post happens, but you can still do something. If not directly, then by contacting your politicians, raising the issue, or by supporting organizations like Médecins Sans Frontières, who help the rape victims.

The silence and inaction must end.

Labels: , , ,

Scientia Pro Publica

Image: wemidji (Jacques Marcoux).

Nam et ipsa scientia potestas est (And thus knowledge itself is power)
-- Sir Francis Bacon.

Welcome to the 5th round of Scientia Pro Publica. The Scientia Pro Publica (Science for the People) blog carnival celebrates the best science, nature and medical writing targeted to the public (instead of to other scientists) that has been published in the blogosphere within the past 60 days.

I apologize in advance if the carnival seems a bit incoherent, but due to a mild allergic reaction to something I ate yesterday, my tongue started to swell up, and I didn't sleep as much as I'd have liked. Apparently it's possible to get allergic reactions to food, without being allergic. This is a piece of medical knowledge I'd been perfectly happy to have gained through a blogpost somewhere.

Before starting on the submissions, I should probably mention that a number of the submissions didn't make it to the carnival. The aim of the carnival is to bring science to the public, which means that submissions should both contain science and be suitable for the general public. A number of submissions failed to live up to the science criteria, and thus haven't been included. Some of the submissions that did make it, might not be as suitable for the general public as one would have liked, but overall I felt that they merited inclusions.

GrrlScientist presents a book review of Jerry Coyne's Why Evolution is True

Bora Zivkovic presents Yes, Archaea also have circadian clocks!

Given the media coverage of the discovery of Ida, I was surprised that there wasn't more submissions on that subject. Luckily Greg Laden has submitted a great post on Ida the Fossil Primate

Bob O'Hara presents Help! How Do I Deal With Microarrays?

AK presents Wiring the Cell for Power

Human/Veterinary Medicine
jarofthoughts presents Stem Cell Research and you

Mike presents Neuro Brain Thermodynamics

Romeo Vitelli writes about the Vaccination Wars in two parts. Part 1 and part 2

Michelle Dawson presents The autistic way of laughing

I will be rude enough to include my own post on the Dunning-Kruger effect.

DrKuha describes his submission as "Attempting to draw comparisons between Phlogiston Theory and the Higgs boson and String Theory in an effort to shed some light on how scientific insight is gained."
The Phlogiston: Not Quite Vindicated

Martial Development takes a good, hard look at Spike TV's new show "Deadliest Warrior", and is not impressed.
Inside Deadliest Warrior’s Combat Simulator

Phil for Humanity describes his submissions thus: "Finally, a plausible explanation as to why time travelers from the future have never arrived into our past or present, assuming time travel will be possible."
Time Travel Theories « Phil for Humanity

Behavioral Ecology/Conservation
Mesquite Pete explains that ets are at risk from mosquitoes as well in his post Pets and Mosquitoes

Jeremy presents Churros and peaches in the Canyon de Chelly

Oceanography/Marine Biology
At Mauka to Makai Overfishing Simplified... Then Complexified

Scientists and Society
Arj presents a book of Perfectly Reasonable Deviations From the Beaten Track in The Inner Feynman

Russell Blackford disagrees with NAS and writes about it in NAS on the compatibility of science and religion

Rick Foreman presents Robotics and Artificial Intelligence - The Next Step in Human Evolution?. I should perhaps note that I am not in agreement with his premises, but I think it's a pretty good fit for the "scientists and society" category, as it reflects on how science might influence society.

Southern Fried Science has a Guestpost: What is Social Science?

Bob O'Hara presents Publicity and Outreach Done Wrong. Sounds like he has found the right way to promote his papers.

The final submission I'm going to include, is one I had to debate whether really fitted the format or not. I've pretty much reached the conclusion that it doesn't but, thought "what the heck".

Hank Roberts submitted a link to a YouTube video, which I've embedded. He writes the following:

I've known about these folks for quite a while; they're completely serious and dedicated to what they're doing. I"m not involved with them, just a fan. If their video qualifies as a blog article, this is worth attention.

As I said, this is not really the right format for this carnival, and people should not expect future YouTube submissions to be included.

This ends this round of Scientia Pro Publica. I hope you have enjoyed the posts, and that my lack of sleep hasn't been too apparent.

The next edition of Scientia Pro Publica will be up at target="window" href="">Mauka to
Makai in two weeks, so make sure to submit all your science posts aimed at the public.

Labels: , ,