Ernie’s 3D Pancakes has a post on anonymous academic bloggers. To me, this is an interesting question. I use my own name everywhere on this blog. You can easily figure out where I work, what I teach and to whom, where I publish and so on. You can even find who my son is and so on. I think that Jeff correctly points out that feeling you need to be anonymous is probably misguided. The likelyhood that a colleague is going to come to my blog, read it, be insulted, and try to hurt me on the job, is very, very slim. One reason for that is that I would never bad mouth a colleague on my blog: it just wouldn’t be fun and interesting for my target audience. The likelyhood that a reviewer of a paper I submitted would come on my blog and be insulted and reject my paper is also very slim. However, reviewers have many more reasons to wrongly reject a paper and if you start worrying about this sort of thing, you are not out of the woods!
So, I use my own name. There.
Slashdot reports on a USA Today article saying that there fewer Computer Science Majors. They cite a 23% decline in enrollment in North America. Here’s one comment about the article:
Most engineering schools are reporting declines in enrollment. This is hardly surprising since most engineering curriculums, including CS, are difficult compared to other fields of study. Without the prospect of a good job waiting for them, many college students are veering away from these majors.
Update: Yuhong correctly points out that this is mostly at the undegraduate level. Graduate schools are finding enough students, at least according to Yuhong. I think this is expected: if job prospects are bad, people won’t enter the system but once they’ve entered it, they will stay in it longer if jobs are scarse.
RDF is everywhere it seems: from Dublin Core to RSS, all to way to FOAF… However, it can be quite painful to parse. Cool tools are starting to emerge however, but google is not yet very good at finding them.
Suppose you have a RDF/XML representation and you want the triples… go to W3C RDF Validation Service and it will do it nicely for you.
On the other hand, the form on this page allows you to go from N3 (the user friendly RDF syntax) to RDF/XML.
Through Downes’, I found this great post about how to be creative. HOWTOs are always interesting and sell magazines, but they are somewhat more interesting in blogosphere because someone you can get to know put his heart into it.
- Ignore everybody
- Creativity is its own reward
- Put the hours in
- If your biz plan depends on you suddenly being “discovered” by some big shot, your plan will probably fail
- You are responsible for your own experience
- everyone is born creative; everyone is given a box of crayons in kindergarten
- Keep your day job
- Companies that squelch creativity can no longer compete with companies that champion creativity
- Everybody has their own private Mount Everest they were put on this earth to climb
- The more talented somebody is, the less they need the props
- Don’t try to stand out from the crowd; avoid crowds altogether
- If you accept the pain, it cannot hurt you
- Never compare your inside with somebody else’s outside
One of the most interesting one is number 5: Nobody can tell you if what you’re doing is good, meaningful or worthwhile. The more compelling the path, the more lonely it is.
Of course, I don’t buy all of it. Being extremely lonely is no way to be creative I think. Nobody gets awfully creative at the bottom of a cave. I do think you have to look for others. The strength of your network is key because it multiplies your own brain power. I guess we go back to Emerson’s independence of solitude. Be in a network, be in a crowd, but do not be a mere node in the crowd, be your own node. It does require courage though, and you have to expect to fail, fail badly even.
Paul Graham wrote an essay called ‘Great Hackers‘. I’m pretentious enough to call myself a hacker (though I do not claim to be great), so I had to jump on it!
Here are some juicy quotes…
Good hackers find it unbearable to use bad tools. They’ll simply refuse to work on projects with the wrong infrastructure.
Great hackers also generally insist on using open source software. Not just because it’s better, but because it gives them more control.
They [great hackers] work in cosy, neighborhoody places with people around and somewhere to walk when they need to mull something over, instead of in glass boxes set in acres of parking lots.
There’s no way around it: you can’t manage a process intended to produce beautiful things without knowing what beautiful is.
And this is the reason that high-tech areas only happen around universities. The active ingredient here is not so much the professors as the students. Startups grow up around universities because universities bring together promising young people and make them work on the same projects. The smart ones learn who the other smart ones are, and together they cook up new projects of their own.
If you’re worried that your current job is rotting your brain, it probably is.
If you’ve been annoyed about the fact that a kilobyte has 1024 bytes and not 1000 bytes, well, you were right all along! What people call a kilobyte is really a kibibyte. (Thanks to Owen for pointing it out to me!)
|Examples and comparisons with SI prefixes|
|one kibibit|| 1 Kibit = 210 bit = 1024 bit|
|one kilobit|| 1 kbit = 103 bit = 1000 bit|
|one mebibyte|| 1 MiB = 220 B = 1 048 576 B|
|one megabyte|| 1 MB = 106 B = 1 000 000 B|
|one gibibyte|| 1 GiB = 230 B = 1 073 741 824B|
|one gigabyte|| 1 GB = 109 B = 1 000 000 000 B|
Source: Definitions of the SI units: The binary prefixes
Michael just finished his essay: Principles of Effective Research. I think it is a must read for all Ph.D. students, young researchers, and even idiots like me who always get it wrong. Michael takes a very refreshing view to what research is all about. He is not cynical yet he is true to what research really is. You may never win the Nobel prize if you follow his guidelines, you may never be a guru researcher, but I think you’ll be a good or even excellent researcher. As he explains, being an influent researcher is not a subset of being a good researcher, and that’s a very important statement. In any case, Michael did all of us a favor and I hope that he essay is read by a lot of people. (Power of the network?) I implore you all: link to his essay!!!
Through Downes’, I found an interesting paper on the application of collaborative filtering to e-Learning in ITDL (by Jinan A. W. Fiaidhi).
It makes the point quite well that we must differentiate heterogeneous settings from sane laboratory conditions:
Searching for LOs within heterogeneous repositories as well as within collaborative repositories is far more complicated problem. In searching for such LOs we must first decide on appropriate metadata schema, but which one!
Through Didier and Nielsen, I found a list of Golden Rules for Successful Scientific Research attributed to Dijkstra.
- “Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward.”
- “We all like our work to be socially relevant and scientifically sound. If we can find a topic satisfying both desires, we are lucky; if the two targets are in conflict with each other, let the requirement of scientific soundness prevail.”
- “Never tackle a problem of which you can be pretty sure that (now or in the near future) it will be tackled by others who are, in relation to that problem, at least as competent and well-equipped as you.”
Of the three rules, only the last one seems important. The second one appears self-evident: you want to be socially relevant, but not to the point of producing low quality work. This being said, most researchers go to the other extreme and ignore social relevance and their work loses out its motivation. If you tackle a problem that only you care about, don’t expect much recognition. I actually disagree with the first rule: small problems, technical issues actually often hide interesting problems. Always focusing on the management and top level issue is a bad idea I think. Michelangelo was painting a church! In research, do not be so quick to think that there are noble and not-so-noble problems. All problems can be interesting and knowledge of technical issues can bring much insight.
Blogging is a fascinating past-time. Who would have thought? I just read bits and pieces of an essay on Extreme Thinking.
Here’s a fascinating quote:
The key to keeping this independence of solitude is to develop a long-term vision so compelling and well-internalized, that it can override behaviours for which the short-term rewards are significant, but which may be damaging in the long run.
Update: Independence of solitude: I didn’t know this expression. Found 600 or so hits on Google. Seems that maybe the expression comes from Ralph Waldo Emerson.
What I must do is all that concerns me, not what the people think. This rule, equally arduous in actual and intellectual life, may serve for the whole distinction between greatness and meanness. It is the harder, because you will always find those who think they know what is your duty better than you know it. It is easy in the world to live after the world’s opinion; it is easy in solitude to live after our own; but the great person is one who in the midst of the crowd keeps with perfect sweetness the independence of solitude.