June was a good month. I had a week off from work, in the week before the weather turned really hot.
I did lots of gardening - always in the morning when it was cool. I now have a neat front hedge and a nice clean garden shed. The lawn has given up growing in this heat.
The big thing was buying three toys. A Bose Colour bluetooth speaker to replace the Roberts radio by my bedside. Now I can stream from all the music on my NAS via my iPhone. Falling asleep to some Gregorian Chant makes a welcome change from Chill on DAB. Second toy was a replacement laptop for my ageing Samsung. It’s an Acer Aspire with an Intel 8X chip, a 1TB HDD and a 1080p screen with wireless AC, and it was just over £500. I ordered that from Amazon and it arrived in July. Third toy was the Sonos Beam soundbar I saw in the Sonos shop in Covent Garden. It was on pre-order, and that’s coming in July as well. I’ve been thinking about all that stuff for a while, and getting all that sorted out was a good feeling.
I read Len Deighton’s Bomber, Micahel Jago’s The Man Who Was George Smiley, Sabine Hossenfelder’s Lost In Math, Eric Ambler’s The Mask of Dimitrious, Andre Breton’s Nadja and Laurnet Binet’s The 7th Function of Language. Bomber really is something else, at times approaching a new kind of hyper-realist literature.
I saw Jeune Femme, Zama, and L’Amant Double at the Curzon Bloomsbury; and Hereditary at the Curzon Soho. I’ve now used all my four free tickets that come with Curzon memberships, and good value that makes it as well. I got through S5 of House as well.
I had supper with my mate in Richmond, and supper with Sis at Gymkhana. Gymkhana is way too expensive for what it is, which is not even, I think, superior Indian food. It’s not a lot better than you’ll get from your local takeaway. I also had supper at Tapas Brindisa (okay) and lunch at Polpo (good) in Soho, the Fish Market at Liverpool St (good), and lunch at Vinotecha (disappointing).
I started on the Great CD Ripping project. Using iTunes, which no less an authority than Hans Beekhuyzen says is fit-for-purpose. Classical CD’s and artwork? Only a handful had it, the rest has to downloaded from Amazon or Google.
Monday, 16 July 2018
Thursday, 28 June 2018
First Sunny Saturday of the Year - Breakfast
I passed Balans Cafe at thought, I wonder if they will do me a bacon sandwich and a coffee, even though it's not on the menu? They did, and I settled in, opened up my iPad and must have fumbled, brought the camera up, and took this by accident.
Labels:
photographs
Monday, 25 June 2018
Anthony Bourdain PBUH
Most of the Big Shots have by now weighed in on the death of Anthony Bourdain. I never met the man, but I’ve been mistaken for him a couple of times. The Big Shots blame his Blue Pill attitude and the behaviour of his two previous partners, both of whom were women you’d take to meet your psychiatrist rather than your mother. What killed Bourdain, they suggest, was the emotional shock of seeing paparazzi photographs of his current partner with someone young, hotter and harder. The hope fell out of his Blue Pill world and he killed himself.
To which I say: no man has ever killed himself over a woman’s infidelity, except in cheap romantic stories. Suicide is done in an absence of feeling: self-pity and despair over an unfaithful girlfriend are rich, life-structuring emotions, not a precursor to suicide.
Bourdain was in Rome to make a TV programme when he saw the photographs. He quit heroin in the 1980’s, but nothing he said or wrote suggested he was working a programme of recovery. He may have decided that a little something would ease the self-pity and help him get through filming. Why wouldn’t he have used his media connections? Because they would not have helped him. Would you have helped supply him? So out onto the street he went. Addicts without a programme do that. Everyone flinches, the trick is not to flinch so a syringe-full of dodgy street drugs ends up in your arm.
And, no autopsy? Rushed cremation? Asia Argento’s father is a well-known film director whose many friends perhaps did not want to see those close to him upset by over-zealous bureaucratic procedures.
In other words, if Our Tony had not been an addict, he would still be alive. But then, if he hadn’t been an addict, he wouldn’t have been Anthony Bourdain.
To which I say: no man has ever killed himself over a woman’s infidelity, except in cheap romantic stories. Suicide is done in an absence of feeling: self-pity and despair over an unfaithful girlfriend are rich, life-structuring emotions, not a precursor to suicide.
Bourdain was in Rome to make a TV programme when he saw the photographs. He quit heroin in the 1980’s, but nothing he said or wrote suggested he was working a programme of recovery. He may have decided that a little something would ease the self-pity and help him get through filming. Why wouldn’t he have used his media connections? Because they would not have helped him. Would you have helped supply him? So out onto the street he went. Addicts without a programme do that. Everyone flinches, the trick is not to flinch so a syringe-full of dodgy street drugs ends up in your arm.
And, no autopsy? Rushed cremation? Asia Argento’s father is a well-known film director whose many friends perhaps did not want to see those close to him upset by over-zealous bureaucratic procedures.
In other words, if Our Tony had not been an addict, he would still be alive. But then, if he hadn’t been an addict, he wouldn’t have been Anthony Bourdain.
Thursday, 21 June 2018
Building Site, Charing Cross Road
Most of this is hidden behind street-level boarding. You have to be in the Gents WC in Foyles to get this view. I don't know why Foyles has a loo, but I've needed it a couple of times and I'm darn grateful it has one. The urge to go interferes terribly with the concentration needed for serious browsing!
Labels:
photographs
Monday, 18 June 2018
How To Run a Python program? And Why Is It A Good Thing?
Isn’t that a question with an obvious answer? Not so much. Answering it takes us to the heart of how Python works.
Write a Windows program in a language such as C#, and the IDE compiles to a self-contained .exe file (as much as any .exe is ‘self-contained’ when it makes calls to all those Windows DLL’s). My reflexes have been developed on languages like that: compile and run.
So my first thought, having got code that worked as it was supposed to, was to make an .exe file. It was then I found out that PyCharm doesn’t compile Python scripts as, say, a C# IDE does. If you really want an .exe file, you have to find a third-party application to compile the scripts and wrap in all the dependencies. The most popular way of doing that is to use Py2Exe. That only works on Python 2.7, and hasn’t been upgraded to handle the 3.x versions of Python. Lesson in there somewhere.
The lesson is this. There are two Pythons. One is the scripting language. The other is a program that runs those scripts. That’s why the command line prompt is ‘python mystuff.py’. It’s telling the Python program to run the Python script in ‘mystuff.py’.
The Python program on Windows converts a .py file into something Windows understands. The Python program on OS X converts the same .py file into something OS X understands. So .py files are portable. mystuff.py will run on any computer with a Python program. (Given Python version compatibility.)
Browsers work in the same way. You download a web page full of all sorts of HTML and other programming junk, and the browser interprets it all in terms the operating system understands and throws the result at the computer to run.
Which means that ‘everyone’ has to have a Python install to use a .py script. Well, okay. Would you expect to be able to ‘run’ an Excel workbook without Excel? You need Excel to be installed.
So how do I run the program? Set up a .bat file with the command line in it, and put that in the Start Menu. Click on it, and it will start up like a ‘real’ .exe program. Which is all I need.
Write a Windows program in a language such as C#, and the IDE compiles to a self-contained .exe file (as much as any .exe is ‘self-contained’ when it makes calls to all those Windows DLL’s). My reflexes have been developed on languages like that: compile and run.
So my first thought, having got code that worked as it was supposed to, was to make an .exe file. It was then I found out that PyCharm doesn’t compile Python scripts as, say, a C# IDE does. If you really want an .exe file, you have to find a third-party application to compile the scripts and wrap in all the dependencies. The most popular way of doing that is to use Py2Exe. That only works on Python 2.7, and hasn’t been upgraded to handle the 3.x versions of Python. Lesson in there somewhere.
The lesson is this. There are two Pythons. One is the scripting language. The other is a program that runs those scripts. That’s why the command line prompt is ‘python mystuff.py’. It’s telling the Python program to run the Python script in ‘mystuff.py’.
The Python program on Windows converts a .py file into something Windows understands. The Python program on OS X converts the same .py file into something OS X understands. So .py files are portable. mystuff.py will run on any computer with a Python program. (Given Python version compatibility.)
Browsers work in the same way. You download a web page full of all sorts of HTML and other programming junk, and the browser interprets it all in terms the operating system understands and throws the result at the computer to run.
Which means that ‘everyone’ has to have a Python install to use a .py script. Well, okay. Would you expect to be able to ‘run’ an Excel workbook without Excel? You need Excel to be installed.
So how do I run the program? Set up a .bat file with the command line in it, and put that in the Start Menu. Click on it, and it will start up like a ‘real’ .exe program. Which is all I need.
Labels:
Computing
Thursday, 14 June 2018
Monday, 11 June 2018
Learning Python by Writing An Application (2)
I haven’t written high-security web applications that link to secure back-end databases, so I’m not talking about those. I’m talking about regular, runs-on-your-computer applications with a UI.
Real programmers know that their command-line utility never hangs and has a try...else to make it stop at the first sign of trouble, so they don’t need it to talk to them. I hate it when a program sits there seemingly doing nothing, I want some feedback. There’s a trade-off between speed and user dialogue. No, not progress bars. Progress bars require sizing the job first, so that the progress can be shown as a percentage of the total. Ever noticed that if the number of files you’re copying is large enough, Windows suddenly takes an age doing some mysterious preparation? That’s what I want to avoid. The only way round that is a running commentary. I don’t want much, maybe something like
Scanned N directories, copied M files to (destination)
updated every 10 files. When it’s syncing, I want to see
Scanned N directories, deleted M files from (destination)
(Real Java Programmers would write a log file of every action, along with the time it happened. I’m so glad I’m not a Real Java Programmer.)
Tkinter is notorious for updating at random. I don’t think this is Python’s fault, but the way the OS and hardware parcel out the tasks. So by the time Tkinter gets a moment to display the first confirmation, the whole task might have been done. To get round this, I called my first thread! I’m a VBA-basher in my day job so threading is something exotic and mysterious, like (insert inappropriate analogy here). It solved the Tkinter delay problem nicely.
My program has a button to choose the source directory, another to choose the target, one to Start and one to say Stop. Think about the UI logic. The Stop button should not be active unless there’s copying or syncing going on. The Run button should not be active unless there are valid source and destination directories.
What happens if I copy a file and there isn’t enough spare space on the target disc? At the very least I’m going to get an error message, and so I’d need to handle that. Or I could test for spare space and stop copying when I reach some kind of limit. That’s what I did: read in the spare space at the start, store that in a variable, subtract the copied file size from that value, and stop if the file to be copied is within some limit of the calculated space. Using the constant cuts down on filesystem calls.
What happens when there’s already a file with the name of the being copied BUT the size is different? The program needs to add a suffix to the filename, but then it has to test that that filename doesn’t exist, which sounds like a loop. And don’t forget to put a numerical limit on the number of attempts just in case someone used a silly file-naming convention.
A lot of programming is testing for and resolving edge-cases. For instance, the destination directory should not be the source directory, nor a subdirectory of the source directory. I got the first condition on the first pass, but only thought of the second when writing this. (Documentation reveals many improvements.)
This is all exception and edge-case handling.
In my experience, the actual business functionality, the code that does what you want done, is about ten per cent of the total code. Variable declarations and syntactic seasoning is about another ten per cent. Setting up, controlling and making the internal logic of the UI consistent, will be about twenty-five percent, depending on how complex it is.
All the rest is handling edge cases, data weirdness, potential errors, null values, and other stuff that might trip up the program.
I’m not kidding.
If half your code isn’t testing that things that need to be there for the next step to work are actually there, or for missing values, forcing stuff to be strings when the function expects strings, putting limits on loops in case something you have never thought could happen does happen and the terminating condition is never reached... if you’re not doing all that, and you’re not writing in sensible defaults for when the user has to make a choice, and you’re not testing for when the user does something really dumb because they’re distracted, or walks away for five minutes, or all those other things you don’t want users to do because then your life gets difficult... then you’re going to produce a program that people are not going to use twice.
The difference between a professional and an amateur is that the professional writes all the edge-case and exception handling they can think of. An amateur thinks ‘Well, the user will just have to...’.
Don’t forget to put in a default drive for the source and destination directories, or the getdirectory() function will dump the user deep down a file tree it will take a boring time to get out of and get to where the user should have been in the first place.
Programming isn’t about writing code to do stuff. That’s the easy part. It’s about writing code that makes sure the user and the computer don’t get in the way of the stuff getting done.
Real programmers know that their command-line utility never hangs and has a try...else to make it stop at the first sign of trouble, so they don’t need it to talk to them. I hate it when a program sits there seemingly doing nothing, I want some feedback. There’s a trade-off between speed and user dialogue. No, not progress bars. Progress bars require sizing the job first, so that the progress can be shown as a percentage of the total. Ever noticed that if the number of files you’re copying is large enough, Windows suddenly takes an age doing some mysterious preparation? That’s what I want to avoid. The only way round that is a running commentary. I don’t want much, maybe something like
Scanned N directories, copied M files to (destination)
updated every 10 files. When it’s syncing, I want to see
Scanned N directories, deleted M files from (destination)
(Real Java Programmers would write a log file of every action, along with the time it happened. I’m so glad I’m not a Real Java Programmer.)
Tkinter is notorious for updating at random. I don’t think this is Python’s fault, but the way the OS and hardware parcel out the tasks. So by the time Tkinter gets a moment to display the first confirmation, the whole task might have been done. To get round this, I called my first thread! I’m a VBA-basher in my day job so threading is something exotic and mysterious, like (insert inappropriate analogy here). It solved the Tkinter delay problem nicely.
My program has a button to choose the source directory, another to choose the target, one to Start and one to say Stop. Think about the UI logic. The Stop button should not be active unless there’s copying or syncing going on. The Run button should not be active unless there are valid source and destination directories.
What happens if I copy a file and there isn’t enough spare space on the target disc? At the very least I’m going to get an error message, and so I’d need to handle that. Or I could test for spare space and stop copying when I reach some kind of limit. That’s what I did: read in the spare space at the start, store that in a variable, subtract the copied file size from that value, and stop if the file to be copied is within some limit of the calculated space. Using the constant cuts down on filesystem calls.
What happens when there’s already a file with the name of the being copied BUT the size is different? The program needs to add a suffix to the filename, but then it has to test that that filename doesn’t exist, which sounds like a loop. And don’t forget to put a numerical limit on the number of attempts just in case someone used a silly file-naming convention.
A lot of programming is testing for and resolving edge-cases. For instance, the destination directory should not be the source directory, nor a subdirectory of the source directory. I got the first condition on the first pass, but only thought of the second when writing this. (Documentation reveals many improvements.)
This is all exception and edge-case handling.
In my experience, the actual business functionality, the code that does what you want done, is about ten per cent of the total code. Variable declarations and syntactic seasoning is about another ten per cent. Setting up, controlling and making the internal logic of the UI consistent, will be about twenty-five percent, depending on how complex it is.
All the rest is handling edge cases, data weirdness, potential errors, null values, and other stuff that might trip up the program.
I’m not kidding.
If half your code isn’t testing that things that need to be there for the next step to work are actually there, or for missing values, forcing stuff to be strings when the function expects strings, putting limits on loops in case something you have never thought could happen does happen and the terminating condition is never reached... if you’re not doing all that, and you’re not writing in sensible defaults for when the user has to make a choice, and you’re not testing for when the user does something really dumb because they’re distracted, or walks away for five minutes, or all those other things you don’t want users to do because then your life gets difficult... then you’re going to produce a program that people are not going to use twice.
The difference between a professional and an amateur is that the professional writes all the edge-case and exception handling they can think of. An amateur thinks ‘Well, the user will just have to...’.
Don’t forget to put in a default drive for the source and destination directories, or the getdirectory() function will dump the user deep down a file tree it will take a boring time to get out of and get to where the user should have been in the first place.
Programming isn’t about writing code to do stuff. That’s the easy part. It’s about writing code that makes sure the user and the computer don’t get in the way of the stuff getting done.
Labels:
Computing
Subscribe to:
Posts (Atom)