The BBC iPlayer radio app is going to stop working in January on iOS7. I understand the overhead in supporting multiple platforms, so I'm not going to complain about that. The iPlayer will still be available on the web though.
I general listen to iPlayer radio while I'm washing up, which is around 6:30-7:30. I generally miss the start of the Radio 4 6:30 comedy slot, so I often listen to the previous working day's programme instead. In order to speed navigation to the previous day (or the one before that) I've made this page which will take you to the evening schedule for 1, 2, 3, or 7 days in the past. Enjoy.
iPlayer Radio 4 on previous days
I have my fingers in many pies: IT/techie/charity/non profit/nptech/mission stuff. Founded 2004
Many Pies
Wednesday, November 30, 2016
Wednesday, November 16, 2016
My decade on Twitter
Inspired by Jeremy Keith's post A decade on Twitter, I'm doing my own. My first tweet was in July 2006, with a 4 digit id, but so much less interesting than Keith's:
See also, written 7 years ago, Twitter is big, which has subtle boasting about my early adopter status, and also when I heard it mentioned on radio. Another thing I remember from the early days, is when people were saying "there's a real celebrity on here - Wil Wheaton". It was such a geeky thing that we were surprised that someone famous would want to use it. Hard to imagine now, eh?
Since then I've gained a large proportion of spam followers, many of them seemingly from Turkey, for no reason I can discern. I've seen what felt like a clubhouse turn into a commercial establishment, with adverts all over the place. I understand that it takes money to run, but after it ran with for many years at the start without adverts, they seem to have taken over relatively quickly. Part of it is the fact that I no longer regularly monitor my two lists ("work" and "play") which have all those I follow on them. As lists don't seem to have adverts the switch to the Twitter app brought a lot more to my attention.Test— Paul Morriss (@paulmorriss) July 14, 2006
See also, written 7 years ago, Twitter is big, which has subtle boasting about my early adopter status, and also when I heard it mentioned on radio. Another thing I remember from the early days, is when people were saying "there's a real celebrity on here - Wil Wheaton". It was such a geeky thing that we were surprised that someone famous would want to use it. Hard to imagine now, eh?
Labels:
twitter
Tuesday, August 23, 2016
Internaut day - 25 years ago I got onto the web
25 years ago I heard about this program from a USENET newsgroup called Mosaic. I downloaded and installed it. As they say: Mind. Blown. All the pages had a grey background. The images would download one by one, and you could see each line of pixels loading. A later version would download the pictures simultaneously.
I remember downloading a quicktime movie of a jet powered sledge. It took ages, but it was groundbreaking.
Someone once asked me about the difference between the web and the internet. I didn't give a very good answer, but since then I've though of a good analogy: we had roads (internet) before we had cars (webpages). Other traffic travels on the roads like horses (FTP) but it's mostly cars (webpages).
I remember downloading a quicktime movie of a jet powered sledge. It took ages, but it was groundbreaking.
Someone once asked me about the difference between the web and the internet. I didn't give a very good answer, but since then I've though of a good analogy: we had roads (internet) before we had cars (webpages). Other traffic travels on the roads like horses (FTP) but it's mostly cars (webpages).
Labels:
web
Thursday, August 18, 2016
Yes, we are turning it off and on again
The Wycliffe UK and Ireland blog contains a post about the project that is taking most of my time at the moment. For those who'd like more technical details, here are some:
The "all-encompassing systems upgrade" refers to the change from Raiser's Edge, our donor management system, to the Causeview app on Salesforce, as I've blogged about in my post Raiser's Edge to Causeview/Salesforce.
The main work before go live is both data migration and configuration. I've got a post in draft about configuration, as there's quite a lot that can be done, as well as some things you just can't do, without re-writing a given feature from scratch, or getting another app to do it.
In my previous post I didn't credit the company that's helping us with the implementation: Purple Vision. They have the primary relationship with Breakeven, the company that produces Causeview, in order to make sure that it does what we want (because Causeview does it, because they've customised it, or because we've customised it). They are also doing some training, I'm not doing it all myself.
If you want even more technical details, please feel free to comment or contact me directly. (Enough people manage to find me so I think you can work out how to do that.)
The "all-encompassing systems upgrade" refers to the change from Raiser's Edge, our donor management system, to the Causeview app on Salesforce, as I've blogged about in my post Raiser's Edge to Causeview/Salesforce.
The main work before go live is both data migration and configuration. I've got a post in draft about configuration, as there's quite a lot that can be done, as well as some things you just can't do, without re-writing a given feature from scratch, or getting another app to do it.
In my previous post I didn't credit the company that's helping us with the implementation: Purple Vision. They have the primary relationship with Breakeven, the company that produces Causeview, in order to make sure that it does what we want (because Causeview does it, because they've customised it, or because we've customised it). They are also doing some training, I'm not doing it all myself.
If you want even more technical details, please feel free to comment or contact me directly. (Enough people manage to find me so I think you can work out how to do that.)
Labels:
Raiser's Edge,
Salesforce
Thursday, June 09, 2016
Raiser's Edge to Salesforce/Causeview - pros and cons
I'm in the middle of working on migrating our Raiser's Edge data to the Causeview app on Salesforce. This is not a high level list of the really important things, but a list of things I've found, which may or not be important to you. Note that by Raiser's Edge I mean the classic interface, not the new web-based RE NXT, which we're not using at the moment. I'd be interested to hear how RE NXT fares in these areas.
At the moment I'm uploading and downloading tens of thousands of constituent records, and SF performs much better than our on-premises SQL database.
Data loader can be run from command line.
Upsert.
There is much more customisation possible with the layout of the page. This is particularly useful as a page can be quite long, so you can hide sections that you never use.
Duplicate checking is better than RE's since they "improved" it a few years ago and it got worse.
Global search across lots of fields.
You're using a web interface, which doesn't have the slickness of a native app. I suspect when it comes to data entry people are going to have to be switching between keyboard and mouse a lot. If you start tabbing to try and get to the first editable field on a page, it's going to take a while.
The data loader doesn't let you validate before adding data. You just have to run it and then fix the errors in the records that failed. (Other dataloaders are available, I haven't investigated yet.)
The data loader tells you of duplicates, but doesn't tell you what other record looks like a duplicate.
Causeview documentation isn't very complete. None of the context help I've tried has worked.
Gifts are split into three parts - transactions, payments and allocations. So you don't have to click between tabs on an RE record, but you do have to click between pages in order to find out information about gifts.
Objects have names which aren't very helpful. For example, Funds have names like F-01768. They have a description, and a separate fund code, which we set to the names and codes we've been using previously. However throughout the interface, if it's going to display one thing, it will choose the name, which is pretty meaningless and can't be changed.
Pro
Salesforce has a better report writer than RE - you can work with pivot tables without having to resort to Excel, and you can put two reports side by side for comparison. You can create graphs and display them in a given constituent record, again without having to use Excel. (RE does have graphical dashboards.)At the moment I'm uploading and downloading tens of thousands of constituent records, and SF performs much better than our on-premises SQL database.
Data loader can be run from command line.
Upsert.
There is much more customisation possible with the layout of the page. This is particularly useful as a page can be quite long, so you can hide sections that you never use.
Duplicate checking is better than RE's since they "improved" it a few years ago and it got worse.
Global search across lots of fields.
Cons
You only get 1Gb of storage, without having to pay more. I appreciate that it's not quite the same as 1Gb of RAM in a desktop PC, in that it's replicated, and backed up etc. Still though, that's not a lot of space for storing your data.You're using a web interface, which doesn't have the slickness of a native app. I suspect when it comes to data entry people are going to have to be switching between keyboard and mouse a lot. If you start tabbing to try and get to the first editable field on a page, it's going to take a while.
The data loader doesn't let you validate before adding data. You just have to run it and then fix the errors in the records that failed. (Other dataloaders are available, I haven't investigated yet.)
The data loader tells you of duplicates, but doesn't tell you what other record looks like a duplicate.
Causeview documentation isn't very complete. None of the context help I've tried has worked.
Gifts are split into three parts - transactions, payments and allocations. So you don't have to click between tabs on an RE record, but you do have to click between pages in order to find out information about gifts.
Objects have names which aren't very helpful. For example, Funds have names like F-01768. They have a description, and a separate fund code, which we set to the names and codes we've been using previously. However throughout the interface, if it's going to display one thing, it will choose the name, which is pretty meaningless and can't be changed.
Labels:
Salesforce
Friday, March 18, 2016
Salesforce and the 2016 Stack Overflow survey
I blogged last year about the fact that Salesforce was most dreaded in the Stack Overflow survey but I'm pleased to say it's 8th in this year's survey. I'm going to be some development in the next few months, so it's good to know there are worse things.
Interestingly, when it comes to job priorities "British developers are more concerned with location" than salary.
Interestingly, when it comes to job priorities "British developers are more concerned with location" than salary.
Labels:
development,
Salesforce
Wednesday, January 27, 2016
Emojis are a serious matter
Emojis are increasingly popular. ✏ If you can see a pencil before the word "If" then the device you're using has some support for them. They may seem like a bit of fun, but the fact that they have been included in the Unicode standard since 2010 means they are actually pretty serious. Or rather, that they are a valid means of communication which the Unicode Consortium has recognised.
😁 I don't see an emoji Bible coming anytime soon though (someone did have a go at creating a Kickstarter project for one).
🚀
The Unicode standard has new characters introduced at every revision, and for some revisions this includes new emojis. If you can see a chilli pepper here then you're up to date: 🌶. If you're wondering how they decide whether to include emojis then they've written a document on that.
There is a review process to introduce characters, and often some of the preparatory work in Bible Translation will feed into this review process. One of the early things in Bible Translation is to work out which script should be used. Some languages have never been written down before, and so there's a process involving the people who speak the language to see what they want to do. If it has been written down and some of the characters which aren't in Unicode then they will be submitted to this review process.
SIL, who do a lot of work on language technology have a group called the Non-Roman Script Initiative (NRSI) which has been working on technical issues do with fonts and writing systems. They recently celebrated their 20th anniversary.
😁 I don't see an emoji Bible coming anytime soon though (someone did have a go at creating a Kickstarter project for one).
🚀
The Unicode standard has new characters introduced at every revision, and for some revisions this includes new emojis. If you can see a chilli pepper here then you're up to date: 🌶. If you're wondering how they decide whether to include emojis then they've written a document on that.
There is a review process to introduce characters, and often some of the preparatory work in Bible Translation will feed into this review process. One of the early things in Bible Translation is to work out which script should be used. Some languages have never been written down before, and so there's a process involving the people who speak the language to see what they want to do. If it has been written down and some of the characters which aren't in Unicode then they will be submitted to this review process.
SIL, who do a lot of work on language technology have a group called the Non-Roman Script Initiative (NRSI) which has been working on technical issues do with fonts and writing systems. They recently celebrated their 20th anniversary.
Labels:
translation,
wycliffe
Tuesday, January 26, 2016
MissioMaze - a new app for Wycliffe Bible Translators UK
Much of what I do is behind our office firewall or password protected websites, but I've been working on something recently that people with an iOS device will be able to see.
Back in 2013 I came across an app called iHobo, which puts a homeless man on your phone for three days. You interact with this homeless man from time to time over the three days - it's not something you do continuously. I thought that same approach could be used with a game which has been round for many years "For those back home". This is a game designed to be played within a group setting. You have a series of choices to make, a bit like the old "choose your own adventure" books. In that game the aim is to get as many converts as possible. However situations come up where you have to choose between what your sending church and what local people might want.
I started by rewriting the questions, as the approaches used in Bible Translation have changed in the 20 or so years when that game was written. For example, many new translation projects in related languages are done in parallel with an overall "cluster" project*. The measure of success changed from number to percentage of the church engaged - how much the local people gain a desire to have and use the translated Scriptures.
As I'm an IT person I got some people who know what they are talking about to review what I'd written. At that point the project stalled due to lack of time and money. Then towards the end of last year it was revived again and I started work on developing the app, while other people worked on refining the questions.
As I had previous experience with the Marmalade framework I used that. I used Marmalade Web which wraps up HTML/Javascript into an app. This was because a requirement was that the game could also be played on a PC at an exhibition stand, and so I wanted to use something simple. For iOS Marmalade Web lets me write an extension in C++ which calls a routine to send a (local) notification after a number of minutes or hours. This is necessary because iOS could close the app when it's not in the foreground.
What's not easy to see on the website, is how you can't get do everything you need to on Windows. Whilst the environment simplifies a lot of the work involved in cross platform building, when it comes to uploading to the Apple App store, you need to use a Mac. I used macincloud.com for this bit. You can rent a Mac for $1 an hour. For ad hoc work you have to buy 30 hours credits, and they expire after a while. That's not a bad price if all you want to do is upload your app.
It's currently going through beta testing - let me know if you want to take part. Keep an eye on the MissioMaze web page for when it's released (we're aiming for March/April).
*From Not too remote
Back in 2013 I came across an app called iHobo, which puts a homeless man on your phone for three days. You interact with this homeless man from time to time over the three days - it's not something you do continuously. I thought that same approach could be used with a game which has been round for many years "For those back home". This is a game designed to be played within a group setting. You have a series of choices to make, a bit like the old "choose your own adventure" books. In that game the aim is to get as many converts as possible. However situations come up where you have to choose between what your sending church and what local people might want.
I started by rewriting the questions, as the approaches used in Bible Translation have changed in the 20 or so years when that game was written. For example, many new translation projects in related languages are done in parallel with an overall "cluster" project*. The measure of success changed from number to percentage of the church engaged - how much the local people gain a desire to have and use the translated Scriptures.
As I'm an IT person I got some people who know what they are talking about to review what I'd written. At that point the project stalled due to lack of time and money. Then towards the end of last year it was revived again and I started work on developing the app, while other people worked on refining the questions.
As I had previous experience with the Marmalade framework I used that. I used Marmalade Web which wraps up HTML/Javascript into an app. This was because a requirement was that the game could also be played on a PC at an exhibition stand, and so I wanted to use something simple. For iOS Marmalade Web lets me write an extension in C++ which calls a routine to send a (local) notification after a number of minutes or hours. This is necessary because iOS could close the app when it's not in the foreground.
What's not easy to see on the website, is how you can't get do everything you need to on Windows. Whilst the environment simplifies a lot of the work involved in cross platform building, when it comes to uploading to the Apple App store, you need to use a Mac. I used macincloud.com for this bit. You can rent a Mac for $1 an hour. For ad hoc work you have to buy 30 hours credits, and they expire after a while. That's not a bad price if all you want to do is upload your app.
It's currently going through beta testing - let me know if you want to take part. Keep an eye on the MissioMaze web page for when it's released (we're aiming for March/April).
*From Not too remote
A language cluster refers to languages that may be linguistically related, and/or from similar geographic regions or cultural backgrounds. Speakers of these languages work together, sharing expertise, training and resources, to develop their languages and work on translation into each language.
Labels:
development,
testing,
wycliffe
Subscribe to:
Posts (Atom)