After a long period of non-blogging, people often explain why was that and promise to blog more, just as if it was some kind of an obligation. I know it’s not, but still I’m going to fall into this pattern and write about not writing.
Which isn’t quite true; in fact I’ve been quite steadily blogging all this time, in my native language: Polish. There are two main reasons for doing so:
- I seem to have a couple devoted readers of my Polish blog: family and friends. I tried to switch into blogging in English, but apparently, they don’t see the me that they used to know when they read me in English. Or whatever the reason was, my friends just wouldn’t read and respond to equivalent posts in English. Blogging in Polish was (and is) more rewarding.
- I don’t have anything interesting to say in the English-speaking world. How come I have things to say in Polish, you ask? Well, I just translate or comment on things I’ve read in English! There are far more interesting things to read in English than in Polish, and I’m trying to bring at least at a glimpse of them to my fellow Poles. I’m sometimes writing original posts, but they happen to be hermetic and making sense only among my Polish friends.
It’s not that I don’t see any good things from blogging in English. To point out a few:
- Good practice in using the language. Although I have opportunities to speak English now, writing is something that trains a different angle of the language use.
- Since I live in an English-speaking country now, it makes sense to have an active English blog as means of getting to know more people, and perhaps even making friends.
- Occasionally, I do have something interesting to say in English. By habit, I write it in Polish and never translate it. I could translate from Polish more often.
- My English blog used to be more of a „tech notes” kind of blog. I think I will still use it to post solutions to problems I solved. Now, mixing personal ramblings with tech notes doesn’t seem like a good idea, because readers interested in personal stuff will be annoyed by those small posts about some Linux command working this way or other. Splitting blogs seems like a sensible thing to do, but I’ve got 3 blogs already and don’t want to multiply entities beyond necessity.
For now, things are going to stay the way they are. Maybe someday I’ll actually have something interesting to say in English. If I do, you’ll find it on my blog.
This blog was initially intended to talk about technical Linux things, then switched into data analysis. Now, since my thesis writing is over and I don’t currently do any data analysis in my work, it has become stagnant.
I’m thinking whether to stick with the data analysis and Linux or to allow myself to write about variety of other topics which I’m following at the moment.
My primary `social’ blog happens to be in Polish. There’s a great on-line community on Jogger, a jabber-enabled (and Google Talk-enabled) blogging site. I definitely still want to stick with it, so my blogging time is to be still divided between Polish writing on Jogger and English writing here.
I definitely want to keep on writing in English, to develop my writing or at least keep it in shape. That might be the main reason to widen the topic range. It would be better than not writing at all.
My dream was to create a blog with great articles, something like Stevey Yegge. Perhaps I won’t work out just yet. I’ll stick with writing small notes. The time for great articles will come.
The ultimate thought about the database would be to have a single patient as a single object that could be entered, tagged, viewed and commented.
Diagnoses, procedures, features, tags
The database can be viewed as a set of patients with features. You can think of features as of something similar to Flickr tags. A diagnosis, a procedure, an age group — are all nothing but features of the patient.
This unification can lead to creation of powerful database exploration method. Having form of a website, the data could be easily browsed (or
firefoxed?) by clicking on the diagnoses, procedures, age groups, etc.
Looking at single tags is interesting already. Looking at the combinations of tags is even more interesting. However, the number of possible tag combinations is enormous. There's need to restrict the set of tags, for example by number of patients that represent it.
Tags could be formed into a tree hierarchy. It's especially important for the nomenclature, as there are few diagnoses or procedures similar enough to be merged.
I don't want to conceal that the concept of the database exploration website is inspired by the existing websites like Flickr, Delicious, Last.fm and last but not least, WordPress. Ideas I'd like to borrow, are:
- Intensive interlinking
- Keyword-rich links
There are much more ideas within Flickr and alike, but I think I'll stop here for now.
The ultimate database interface
The ultimate thought about the database would be to have a single patient as a single object that could be entered, tagged, viewed and commented. It would be a clone of the mentioned websites, specialized in the congenital heart surgery.
This also brings me back to the idea of modeling the heart, as this kind of data model would lead to much more powerful tags than current ones.
Creating a complete environment with data entry is impossible due to a simple fact that it's a thesis of a single computer science student. Me, that is. Having to keep with the schedule, I will concentrate on aggregated data views.
I started submitting to Blogger with Drivel. Now I switched to JPA, written by Jarek Zgoda. The main reason is the textile support which makes the post editing very easy. I don't have to bother with HTML anymore. Textile has all the features one would need to edit an blog entry:
- Bulleted and numbered lists
- Emphasis, bold, citation, superscript, subscript and more
- Left/Right/Justify align
- Footnotes (pretty neat feature, I like them)
JPA allows to write link-rich blog entries easily.
I've seen last.fm being mentioned on many blogs, but I've never tried to take a look at it. Now, I've did take a look yesterday and I was really impressed. Seems like I'm going to become an active last.fm user.
If you're afraid of forgetting something, write it down. Surely I do that. Here is what I found today in my notes:
pstops "2:0L@.7(21cm,0)+1L@.7(21cm,14.85cm)" input.ps output.ps
I think what it does is convert a postscript document from simple A4 document to two pages on one A4. But it's just a guess… because I didn't write down what it does.
I had a period of extreme enthusiasm towards wiki website model. I created an internal wiki for my company, a website about atopic dermatitis, a website about the jazz guitar, a mixed extra-intranet for National Food and Nutrition Institute, a website about yoga (for my girlfriend), a knowledge base for EACTS Congenital Database and, last but not least, a wiki for myself. The last one was used extensively during my stay in Denmark, when I used it to write reports for assignments.
After finishing the courses in Denmark it seems like I'm not using it anymore. So I decided to close it. Static content is going to be published on my HTML based website. Blogs (English and Polish) will be used for temporary things and publishing thoughts.
Nevertheless I do consider wiki a very powerful website model. For example, it's a perfect tool for website prototyping. You can create content for the website with wiki with extreme ease. When the structure and content is more or less ready, you can move the content to more static website model.
So, what's the best use of wiki? I can point out few of them:
- Collaborative website – it can be a community website or a website for some project (software project or an academic course).
- Website prototype – you can easily move content around, create and delete subpages until you get desired website structure.
- Thesis writing – you can easily organize your material and write parts of your thesis. After writing the material you can make a linear version by stitching together content of selected subpages.
If you're about to create a website that matches one of above, consider a wiki model.