Friday, August 31, 2018

The search for the perfect mp3 player

As readers will know, I travel frequently on the train to Karmiel which is a three hour journey going there and three and a half back (there is a twenty minute wait coming back). Less frequently I travel to Tel Aviv or Haifa; during all of these journeys I listen to music so the topic of a good mp3 player is frequently on my mind. For these trips I use the Sony noise cancelling headphones which I bought at the beginning of the year; these provide excellent sound (and I don't hear my fellow travellers) but there is no built in mp3 player, so I need an external one. 

The venerable Sansa Clip is well designed but keeps on starting from the beginning; as I have slightly over 1700 songs on the memory card, it is very annoying at the beginning of each journey to find the song which I last heard. Supposedly this player can start from where it left off the previous time, but when I turn it on, I am presented with a menu which begins "Play all songs". Maybe I should restore the factory defaults and see what happens then.

The cheap ones which I bought in May are ... cheap. At least they continue playing from the last song heard, but their battery capacity is two hours at most. This means that on the trip to Karmiel, I have to extract the memory card from one player and insert it into another. I've given up with these.

I have ordered yet another player from Ebay but this has yet to arrive so I can't comment on it.

For walking around the kibbutz, I have a pair of headphones with a built in player; these are good, the player continues from the last song played (which normally is good, but problematic if the 'song' is a complete album). The headphones themselves aren't as good as the Sony ones, which is not surprising; these barely cover the ears and don't fold, so I don't take them on the train.

What I would like is an mp3 player which continues from exactly where it was when it was turned off (as opposed to playing from the last song heard or from the beginning) and which I can connect, either via cable or Bluetooth to the Sony headphones. I still haven't found what I'm looking for, as Bono once sang.

On the other hand ... one summer activity of mine is swimming. I find this very boring, especially when my stamina builds up and I can swim 20+ lengths. Whilst browsing for mp3 players, I came across an intriguing entry: an mp3 player for swimmers with built in earbuds! As they don't cost very much, I thought that I would take the plunge and order a set. They arrived today and I've been playing with them all afternoon (I'll test them in the pool tomorrow). 

As opposed to the other players, these have no external memory card; the songs are stored on internal memory. They supposedly have a capacity of 8GB, but actually have about 7GB - this is still enough for about 1400 songs which would take a very long time to listen to - much longer than I swim all summer long - so this isn't really a problem. On the other hand, having earbuds means that I can use this player whilst wearing my Italian straw hat. This is a definite plus. The sound quality is not bad at all, provided that one doesn't listen too loud. 

The main problem with this player which I have already established is that accessing the controls is very difficult: the player is supposed to be worn around the neck with the controls at the back of the neck and the leads connecting the earbuds to the player are very short. On the other hand, one is hardly likely to start fiddling with the controls when one is swimming. I imagine that I will turn the player on when I get to the pool, swim then turn it off at some stage. The controls themselves are slightly confusing.

One has to 'break the player in half' in order to extract the player itself in order to load songs and charge it. It's easy to take the player out but slightly harder to replace it. I only hope that replacing it frequently does not ruin the water-tight seal: this player won't be any good if it doesn't survive its first swimming session!

I have yet to establish its behaviour with regard to song order and from where it starts. It seems so far that the player doesn't handle directories, meaning that all songs have to be in the root directory. I seem to recall that a root directory can have at most 512 files; as these players use the FAT system, this may be a problem. At least all (or at least, most) of the files have their playing number incorporated both in the filename (e.g. 2105 Cottonwood) and in the mp3 tag, so this shouldn't cause a problem. I can sort the files to be in physical according to their names, which overcomes another problem. So far, the songs are playing in order. I've only copied about fifty songs which should be enough for the time being.

Thursday, August 30, 2018

Maximum word count for submission

I, like other doctoral candidates, received a letter a few days ago from the DBA operations manager:
From the September meeting of the Doctoral Review Committee (DRC) onwards we will be strictly enforcing a maximum word count for intermediate submissions. Section 1.10.2 of the Introduction to Business Research 2 course recommends a size of 27-30,000 words. The DRC has set the maximum word count at 40,000. Any submissions that exceed this limit will not be considered by the DRC.

I find this somewhat ironic as I was advised a few months ago by my supervisor to cover a few topics which I hadn't originally considered (alignment and horizontal software). As a result, I find now that the intermediate submission as it currently stands has a word count of 36,428 words! The bibliography has slightly over 3,000 words - I don't know whether this is supposed to be included or excluded - but either way, the submission is too large. I found myself going over the submission the other evening and removing papers from the literature review! I shall have to read the literature review and synthesis chapters again, looking for material which I can remove. 

Anyway, I have to rewrite the methodology chapter so hopefully I will be able to lose material which I consider to be extraneous.

Tuesday, August 21, 2018

Hot summer

I see that I have barely written anything here all month. This is primarily because I have been travelling two or three days a week (for example, yesterday I left the house at 5:30am and returned at about 9pm), and on the days when I haven't been travelling, it's been too hot to really do anything. 

This has meant that I have had to be very strict with myself regarding down time, and in the little time that has been left, I have been concentrating on working on the literature review for my thesis, specifically on the subject of 'alignment'. Every time that I thought that I had nearly finished, I found another paper which had to be read and discussed, and then another paper.... Now I think that I have almost finished: I have to write - or at least, improve - the 'synthesis' part, which is my discussion of the papers, what faults they may have (one had a huge mistake in an example) and how the papers fit together.

From there, I will have to rewrite the methodology chapter, which for me is very hard. In all the theses which I have read, this portion seems to be a regurgitation of textbooks with very little personal input. My supervisor writes that I have to explain why I make the choices that I do as opposed to how I intend to collect the data (the how is important, but less important than the why).

And as for myself: I have been working on and off on a new song; the music for the verses is complete and arranged, but I am not sure about the 'middle bit'. The song has a title ('Say what you will') which should help the lyrics, that at the moment have the intention that they be about myself complaining about all sorts of things when in fact my situation is much better than many people. For example, my health bothers me (although my immune system seems to have improved immensely since I started taking theanine) but it's nothing compared to what other people have.

Friday, August 17, 2018

Using indexes

One of my "rules of life" is never to program after 9pm, as I won't sleep well afterwards. Last night I broke that rule and indeed did not sleep well.

Earlier in the evening, I had been working on a problem in the "ERP" program which I wrote for the Occupational Psychologist. One module is concerned with what are called in English 'reconciliations', although a better name might be 'match ups': these record which bill has been paid for by which receipt. There was a problem with one reconciliation for a customer, but I had difficulty in finding this problematic reconciliation.

After walking the dog (at nearly 9pm), it occurred to me that I could write a report which listed all the dubious reconciliations: these would have one or more bills and one or more receipts sharing the same reconciliation number. The query needed was not difficult to write
select bills.recon, count (*) from bills inner join receipts on receipts.recon = bills.recon where bills.customer = :p1 and bills.curdate >= :p2 and bills.recon > 0 group by bills.recon having count (*) > 2;
The only unusual part of that query is the final line: the 'having' clause allows one to compare a calculated value with an ordinal value. The ':p1' and ':p2' variables are parameters to the query.

I ran this query with the appropriate values for the variables and waited ... and waited ... and I thought at first that I had written a query which causes the database manager to crash. But no, after a few minutes - which is comparatively a lifetime - I got results: there was a dubious reconciliation. As I already had determined the same reconciliation manually, I was pleased that the query agreed with me, but I was more concerned with the performance of the query.

Adding a few indexes to the database should help - one on bills.customer (strangely, this was missing as it would help many queries), one on bills.recon and one on receipts.recon (these last two indexes wouldn't have much general use) - and indeed they did. After adding them, the time required for the query was reduced from about 2:15 minutes to 0.15 seconds, which makes the second query 900 times faster than the first! This speed increase was not a function of having the data cached, as I ran the first query a few times to see whether the long time was repeatable (and it was).

Theoretically, there should be an index for every foreign key in a table, but sometimes the value of doing so (faster queries) is outweighed by the cost of the index (slower inserting and updating).  The index on 'bills.customer' should have been there from the start as there are many queries which will benefit from this. The indexes on the 'recon' fields are less important but make a definite improvement here.

And to sign off: yes, I know that index is a Latin word, and as such its plural should be indices. But the original SQL programmers presumably did not have a classical education and so thought that the plural of index is indexes. It makes me shudder every time I write that false plural.