I forgot that a few weeks back I made a commit to Whyteboard's build procedure, that uploads a newly-created file via FTP a website, to allow Whyteboard to check if a new version has been released.
During this commit, I committed a file with my hosting username and password. Silly man!
Thursday, 17 November 2011
Saturday, 29 October 2011
Automating the build and release procedure
In the past I have been frustrated at the amount of time it takes for me to create a build, due to manual tasks that needed to be performed. I have finally taken a step towards an automated build process by creating a series of .bat and .sh scripts for Windows and Linux that perform the boring work for me.
There are a number of scripts, each performing different 'stages' of the build. e.g. on Windows there is build.bat, binaries.bat and release.bat.
Build: Creates the .exe from the Python source and includes all distributable resources etc that are needed into a folder.
Binaries: First, it asks for a version number. It then modifies the program's meta script that defines the version number to ensure it's correctly set.
It then calls the build script above, and then creates an installer file by launching InnoSetup as a GUI-less program. It then creates .zip files for the stand-alone exe and moves the files to a directory ready for release.
Release: It updates the file that is used by the program to look up the latest version number when doing an update check. It then FTPs this to the server.
I've added the option for Pylint to be run against all the program's codebase and output to a file; I'm figuring out how to get my unit tests running from the command line too. I'm looking into whether I can release the binaries to the several sites where I host the program via a REST API or over FTP. This would be a huge improvement.
All in all, this will help me deploy changes much quicker when releasing.
There are a number of scripts, each performing different 'stages' of the build. e.g. on Windows there is build.bat, binaries.bat and release.bat.
Build: Creates the .exe from the Python source and includes all distributable resources etc that are needed into a folder.
Binaries: First, it asks for a version number. It then modifies the program's meta script that defines the version number to ensure it's correctly set.
It then calls the build script above, and then creates an installer file by launching InnoSetup as a GUI-less program. It then creates .zip files for the stand-alone exe and moves the files to a directory ready for release.
Release: It updates the file that is used by the program to look up the latest version number when doing an update check. It then FTPs this to the server.
I've added the option for Pylint to be run against all the program's codebase and output to a file; I'm figuring out how to get my unit tests running from the command line too. I'm looking into whether I can release the binaries to the several sites where I host the program via a REST API or over FTP. This would be a huge improvement.
All in all, this will help me deploy changes much quicker when releasing.
Friday, 10 June 2011
Logging - simple mistake
I recently ran into a problem where my logging started to duplicate each log message, but in a different format after one particular logging call.
I could not track down the error, until I actually read what I wrote:
I'd accidentally called debug on the logging module, not my logger. Everything I was googling was pointing towards enabling the default logging config (e.g.
Easy mistake to make, thought I'd briefly write about it.
I could not track down the error, until I actually read what I wrote:
import logging
logger = logging.getLogger("a.logger")
class Something:
...
logging.debug("a message")
I'd accidentally called debug on the logging module, not my logger. Everything I was googling was pointing towards enabling the default logging config (e.g.
logging.basicConfig()) but I hadn't done so.
Easy mistake to make, thought I'd briefly write about it.
Adding logging to Whyteboard
I've been undertaking quite a large change to the program: logging. Now, the program prints out a log of debug, information and warning logs to help see what's going on. I'm perhaps 25-30% complete in adding the logging, and it's already helping immensely. Just when loading a file for example, I can now see the steps the program takes in figuring out whether to convert a PDF, load a .wtbd file and then the step-by-step actions being performed there. It's great
I'm just not too sure about the best strategy for debugging things like events - e.g. in the mouse motion event handler, which gets called hundreds of times for the Pen tool, we don't want to flood the console.
Also, not too sure about what to do with logging the debug messages to file by default? One of the whole points to all of this is that I can view a user's debug log to see what they did before triggering some exception in an error report.
hmm.
I'm just not too sure about the best strategy for debugging things like events - e.g. in the mouse motion event handler, which gets called hundreds of times for the Pen tool, we don't want to flood the console.
Also, not too sure about what to do with logging the debug messages to file by default? One of the whole points to all of this is that I can view a user's debug log to see what they did before triggering some exception in an error report.
hmm.
Thursday, 11 November 2010
Article on Whyteboard in Dec 2010 Linux Journal
An article has been published in Issue 200, December 2010 of the Linux Journal magazine, in the "new projects" section. Praise was given for its simple UI, PDF annotating abilities, the history replay view and being able to embed multimedia into a sheet.
Wednesday, 15 September 2010
Having a simple website
The Whyteboard home page is simple. Very simple. I was going to create a "modern" site, with some nice javascript goodness and whatnot, but I have trouble creating a website from blank. I'm not much of a design guy - I do a little CSS at work, but not in a few months, and it's always been making changes to existing sites.
So, I've gone the complete opposite and done the most basic site I could. It's pretty much one page with some summarised information about the program.
So, I've gone the complete opposite and done the most basic site I could. It's pretty much one page with some summarised information about the program.
Tuesday, 31 August 2010
Whyteboard 0.41 released!
Hurrah - finally got a release by the end of the month as I was hoping to do.
This version should finally kill off all unicode related bugs - in total, over 15 bugs have been fixed. I'm embarrassed that they slipped through my radar - but at least they're now fixed.
What's new in this release?
- Program now reads in your system language at startup and sets the default locale based on that. No more setting preferences!
- Many enhancements to the "Shape Viewer" dialog
- Misc. UI improvements such as little * shown in the program title when there's unsaved changes.
- Massive code overhauls and changes to make the program easier to develop on
Wow! Looking back it seems like there's not much new...
Download at http://code.google.com/p/whyteboard/downloads/list
This version should finally kill off all unicode related bugs - in total, over 15 bugs have been fixed. I'm embarrassed that they slipped through my radar - but at least they're now fixed.
What's new in this release?
- Program now reads in your system language at startup and sets the default locale based on that. No more setting preferences!
- Many enhancements to the "Shape Viewer" dialog
- Misc. UI improvements such as little * shown in the program title when there's unsaved changes.
- Massive code overhauls and changes to make the program easier to develop on
Wow! Looking back it seems like there's not much new...
Download at http://code.google.com/p/whyteboard/downloads/list
Subscribe to:
Posts (Atom)