- Email, contacts, calendar, file storage and photos I’ve already moved from my server to Google products. I’m no great lover of Google, but having struggled so long with email servers and clients’ spotty DAV support and OwnCloud updates breaking everything, I have to admit it’s so much easier.
- This blog is based on Jekyll and can relatively easily be moved to GitHub Pages. We’d lose HTTPS support, but I don’t think that’s a major issue. ~500MB of images used by it currently sit on
files.ianrenton.combut could be brought into the repository. The challenge is the comments, which use my own Juvia server. There’s no migration path from that to anything, and I do want to keep the comments— particularly on the Raspberry Tank pages—as there’s a lot of helpful information there. Disqus is the logical non-self-hosted equivalent, but there’s no automated way of bringing the comments in. Maybe it’s time to migrate the whole site back to WordPress, since hosted solutions are easier to come by.
- Software executables can use GitHub’s “releases” feature and be hosted there next to the source code.
- Everything else on
files.ianrenton.comis pretty much junk, bits of it can be shared ad-hoc from Google Drive.
- SuccessWhale, Can I Call It, Daily Promise, A Thousand Words and Westminster Hubble are effectively dead at this point. They can be taken down and replaced with portfolio pages saying “this is what I once made”.
- Rimbaud’s House hasn’t been in use for a while anyway, it was a nice project but the camera has not proved useful and I do not trust the sensors enough to introduce full automation based on their readings.
- I host three WordPress sites for other people. Two are potentially old enough that they can be deleted or replaced with static pages; the other I could migrate to WordPress.com although that would involve paying extra.
- My son’s Minecraft server is turned off 99% of the time, but if we do want to bring it back at some point, losing the server would mean losing that capability.
- I do use the server as a VPN occasionally when on unsecured WiFi, but almost every critical app and website uses HTTPS these days, it’s not necessarily essential any more.
- Automatically turn the 12V DC LED light panel on and off at a defined schedule
- Monitor temperature and humidity inside the vivarium
- Automatically control the 240V AC 10W heat mat to keep the temperature within defined bounds
- Send email alerts if temperature and humidity exceed the defined bounds
- Take regular photos of the inside of the vivarium
- Regularly post photo, temperature, humidity and status information to another computer for display on a website
- Fit in a 450x80mm space next to the vivarium (except components that must go inside)
- Be powered from a household 240V AC supply
- Not expose 240V AC to the probing fingers of children.
- The main server runs SuccessWhale version 2.0.3. It’s not been updated in nearly a year, and the only changes within the last three years have been playing catch-up with the changing Twitter and Facebook APIs. It probably has some broken features by now, because I don’t regularly test it out.
- The test server runs SuccessWhale version 2.1.2 with debug flags enabled. The 2.1 branch includes things like mixed feeds and LinkedIn support, and is “beta-ish”. Some people use it anyway. LinkedIn support is broken and will never be fixed.
- The dev server runs SuccessWhale version 3.0.0-dev, a complete rewrite of the whole thing that has stalled in a half-finished state. It’s just about usable provided you’re willing to drop back to the test server to fiddle with any settings (they use the same database). It’s buggy, and as far as I know used only by me.
- Free time is nice. I started SuccessWhale five years ago, when I still had the energy to keep big projects going. Now, with less free time in the evenings and more responsibilities in my day job, I’m much more keen on grabbing a few minutes of that blissful feeling that comes from having nothing to do.
- We created a monster. SuccessWhale (or FailWhale as it was then called) was first and foremost a simple Twitter client. I explicitly declared that it would never be a client for other social networks such as Facebook. Nowadays, SuccessWhale has its own API that wraps both Twitter and Facebook, along with several front-ends.
- Rewrites are no fun. Version 2.0 was badly coded and had to go. Version 3 is nice and designed properly from the start! But it requires hundreds of hours of work just to let it do all the things that version 2 could already do.
- The APIs are crap. In fairness to Twitter, its API is well-documented and makes a lot of sense. But, like all APIs it is regularly updated, meaning that all application developers need to work just to keep up — we put hours in not to add new features, but just to make sure the existing stuff doesn’t break.
Facebook’s API is much the same, except that it makes much less sense and the documentation is largely non-existent. It’s quite telling that I asked a simple question on StackOverflow, and a Facebook dev replied with “here’s how to do it. I guess I’d better add that to the docs, huh?”
- The services are hostile. Twitter, once the darling of those that believed in a strong 3rd-party client ecosystem, are now actively hostile to developers that create clients like mine that “replicate the core Twitter experience”. It’s not nice to develop with a hard 10,000-user limit hanging over your head because you’re making a client for a service that would rather your software didn’t exist.
Facebook isn’t so hostile, but its privacy settings mean that SuccessWhale is only useful to a user if their friends have configured their privacy settings badly.
- The services are crap. Twitter is the playground of celebrities, companies seeking “engagement” and people who want to have a “personal brand”. Its artificial 140-character limits and endless retweets are not a good medium for talking to friends, which is all I want to do. Facebook is a privacy-violating monster on course to balkanise the web with its all-consuming reach. These services are the internet now, and my pleas to return to more honest times fall on deaf ears. But I don’t want to use them, and that makes developing a client for them a distinctly unfulfilling experience.
LAMP stack with “P” being both PHP and Python (or *BSD instead of Linux)
Full shell access
Unlimited (or at least 100 GB) bandwidth
Unlimited (or at least 10 GB) disk space
At least 20 MySQL databases
IMAP mailboxes & mail forwarding
- Facebook support
- Support for multiple Twitter (and Facebook) accounts
- As many columns as you want
- Columns that combine multiple feeds
- Lightboxed images from Twitpic and yFrog
- New themes
- Numerous bug fixes!
Authentication fixed – users using the alternative login weren’t able to do Twitter things. That’s sorted.
Account visibility – your account can now be set to invisible, meaning it won’t appear anywhere – top users, friends lists, etc. New accounts are given a prompt to set their visibility before starting to add promises.
Account deletion simplified – you now only have one, nuclear, option for account deletion. It erases all traces of you having used the site. Do no evil! 🙂
Removed promises no longer shown in the history table – ‘cos no-one likes to be reminded.
Fill in data for yesterday – when creating a promise, users can opt to enter data for yesterday, giving them something to fill in straight away.
History table scrolls – narrow displays can’t fit the whole history table in, so now it scrolls (in reasonably modern browsers).
Time zones implemented – we pull the timezone you have set in Twitter, so Daily Promise will roll over to a new day at your local midnight.
Crontastic! – we now update stats and things from an hourly timed cron, to avoid extra loading on user-requested pages.
All 10 hulls, weapons, engines and radars are now implemented
You can now choose between them when setting build orders, so you can build in whatever configuration you like
Research is now implemented – click on an unresearched component to start researching it
You start the game with only basic components, and must research more to survive
Colours: Grey – not researched yet, Green – researching now, White – available, Yellow – selected (clicking Build will build this)
Enemy AI now handles its own research
Enemy AI now builds intelligently rather than randomly
You can now drag a box to select multiple ships
Base health significantly increased
Building a second ship without moving the first no longer places them on top of one another
Pathfinding code tweaked to cope with much faster/slower ships now all the hulls and engines are available
Fixed an issue whereby the blue radar circles were drawn at half the ships’ actual radar range
Ship / submarine hull and vs ship / submarine weapon distinction
Tweaks to enemy AI
CPU use / mouse responsiveness fixes
Menu system and difficulty picker
Ships are now implemented as having separate Hulls, Weapons, Engines and Radars
Ships can shoot at each other (finally!)
Ships have health (and health bars), and can be destroyed
Bases have health (and health bars), and can be destroyed
That means there’s now a win and a lose condition
Enemy ship AI now considers your ships’ scariness – a factor of firepower and remaining health – to pick targets it thinks it can defeat
You can now build, with appropriate build delays and an 11-slot build queue
The enemy can now build too
Colours have been tweaked to make ships’ allegiances more obvious
Decide on what formatting users can add to stories, and filter for it
Add a word count, and possibly limit submissions to e.g. 600-1400 words
Add a means of reporting stories and pictures for e.g. copyright issues
Add a means of rating stories, so users can mark them as containing sex, violence etc.
Create an admin interface, so we don’t just have to run the site with raw SQL queries
Add ranks, etc. (incentives for achieving high Total Stars)
jQuery up some of the main bits to improve user experience
Implement the scrolling list of pictures for users to select when creating a new story
E-mail address / password authentication, with cookie support based on a secret phrase generated at registration.
Registration itself, including the setting of a display name (users authenticate with their e-mail address, so we need something friendlier to display in the UI). Accounts are created in an unactivated state, and an e-mail is sent allowing the user to use their secret phrase to activate the account (GETted via a “click here to activate!” URL).
Picture submission, which adds the submission to a ‘queue’ table. In time there will be an admin interface for moving items from the queue to the real pictures table, i.e. promoting a suggested picture to “picture of the week” status.
Story submission, which adds the story to the live site and takes you there after submission. There’s currently no edit capability, and the picture that the story is based on must be manually specified by ID number. (The latter will become a scrollable jQuery list of all pictures.)
- Users submit photos or other images that they find interesting
- Every week (or other suitable period of time), one of these is chosen by the site staff
- Users then write short stories, of around 1000 words, inspired by the picture
- Users rate, comment etc. on each other’s stories
- Finish the main page and story page UIs.
- Add bare-bones pages for all the GET/POST functions, e.g. registering accounts, submitting stories, submitting pictures.
- Test all the functions.
- Work on their UIs.
- Start closed beta testing for anyone interested.
- Liberally apply jQuery to improve user experience.
- Add commenting, possibly via DISQUS.
- Add proper user profiles, gravatar support etc.
- Get everyone I can find to try and break it.
- Release! Open the flood-gates, and despair at the dribble I receive.
This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.
As far as I know, SuccessWhale is not being actively used by anyone any more, so I have chosen not to renew the domain name
successwhale.com when it expires today. Like most of my past web-based projects, it will continue to live on at an
onlydreaming.net subdomain, in this case sw.onlydreaming.net, but will not be actively maintained there. As well as its graphical web interface, SuccessWhale also has a back-end API that used to run on a SuccessWhale subdomain. This has now moved to https://successwhale-api.herokuapp.com/. The OnoSendai Android client already uses this address for the API as of update 479, so you may need to update.
Thank you to all the SuccessWhale users over the years!
This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.
It’s been five years now since, full of enthusiasm and convinced that SuccessWhale might make it big, I bought myself a server in London somewhere, and moved my web presence over from its previous shared hosting.
I’ve learnt a lot in those years.
I’ve learnt that despite the “S” in “SMTP”, running a mail server these days is anything but simple. Fighting viruses and spam is challenging, and in particular DKIM is a hassle to get right. I’ve learned that PGP is a nice idea, but I never did find one person to exchange encrypted mail with, or any real reason to do so.
I’ve learned that LetsEncrypt makes setting up SSL certificates much easier and cheaper, but that configuring Apache to serve 23 HTTPS domains from a single machine with SNI is still difficult.
I’ve learned that Linux Version Hell will bite you at some point, and Ruby Version Hell doubly so. Today the server runs three separate versions of Ruby, because not all my Ruby/Rails sites can be run with the same one. The
www-data user has a home directory just for
I’ve learned that drive-by hackers and DoS attackers will find your server, often within hours of it going online, and that fail2ban and mod-blacklist are the sysadmin’s friend.
I’ve learned that Open Source community drama can break stuff you depend on, sometimes without a decent way to recover, and every time you do a package update you risk something not working.
All in all, it’s been a good experience. There have been some frustrating times and late nights fighting with configuration that should just work, but I’ve learned a lot in the process and gained a much greater understanding of how the internet works.
However, I think it might be time to start winding it down. It’s no longer an interesting new experience, it’s just another thing that I have to keep an eye on and ensure it doesn’t break. Life, I find, is better when it’s simpler.
As such I am working up a plan to migrate important things to other services over the coming weeks or months.
A few potential sticking points are:
This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.
“Sea Battle” was a casual 2D real-time strategy game that I put together in a few days back in 2010, and documented in a series of blog posts at the time. It’s lain dormant ever since, but I picked it up again today while bored and made a couple of tweaks.
Six years on, it’s obvious how much my coding style has changed—not only is the formatting dubious and commenting sparse, there’s also a lot of inefficient loops and abuse of global variables. I may change all that in a big refactor at a later date, but for now all I’ve done is a few minimal changes on top of the existing code.
If you played Sea Battle ages ago and fancy trying it again, here’s what to expect:
1) Islands! You now get some randomly-generated islands to break up the wide expanse of blue sea. They’ll be different each time you run the game. Collision detection is based on the old code for detecting collisions with other ships, which is not great, but your ships shouldn’t get stuck behind islands too much. Islands only affect movement, not the firing arcs of weapons.
2) Death list! I originally wanted to give ships randomly-generated names in this update, so you could see something like “Bismarck sank HMS Hood”. However, I couldn’t find a nice way to display them on the play field without adding loads of clutter—maybe one to save for the full-screen 3D version 2. 🙂 The implemented list instead shows which equipment the ships had, e.g. “220.127.116.11” = 1st hull, 2nd weapon, 3rd engine, 4th radar, to give you an idea what your enemy’s current tech level is and what’s working well against what.
3) Equipment changes! I’ve simplified some of the abbreviations for different equipment types so they’re less confusing. Submarine types (SSK and SSN hulls) have been dropped, as it never really made sense to have submarines with 15-inch cannons anyway.
HMS M1, a submarine with a 12-inch cannon. It could only fire one shot before being reloaded, which required it to stay surfaced. Needless to say, it did not see operational service. (Image: Wikimedia)
4) Removed dodgy monotype fonts! Not sure what I was thinking with these really. All fonts have been removed from the source package, the whole UI now just uses your system sans-serif font.
5) Build time rebalancing! Build times used to be dependent on hull size alone. This made it (spoilers!) preferable to research only weapons and radar, and flood the field with quick-to-build ships that did high damage and outranged the enemy so they could get a couple of shots off before dying. (The AI prefers this approach on higher levels too.) Now, although hull still dominates, the other equipment affects the build time too. For example, Hull 1 Weapon 10 Engine 1 Radar 10 used to take 4 seconds to build, it now takes 13.
6) An extra bug fix—playing a new game after a win or loss now resets the world properly.
“Hackerspaces”, or “Makerspaces” are very much an idea whose time has come. The analogy I liked to use most was that of a “community garden shed”—they are places run by the community, where any member can come along and work on their personal projects and collaborate with others.
This is the story of the Dorset Constructorium, a hackerspace that never quite made it.
Note: This is our story as I remember it, published in case others interested in starting a hackerspace of their own find some use in it. I welcome additions and corrections from other members of the group with a better memory of what happened when than mine. I’ve also left out people’s names for now, let me know if you are happy for me to use your name.
Our group began in the Spring of 2013, the way things do—a couple of friends sat around a table and decided they should start a hackerspace. We came up with a goofy but catchy name, “The Dorset Constructorium”. We started a mailing list using Google Groups, which slowly grew to 40 or 50 subscribers, and an IRC channel that hit around a dozen. Throughout that year we used them to organise some meetings in pubs in Bournemouth and Wimborne, where we chatted and drank and discussed how we could move on from our current arrangements to become a real hackerspace.
Evenings down the pub were all well and good, but we couldn’t be a hackerspace without a space.
We started looking, making calls and sending emails to likely groups: companies, community centres, halls for hire. We filled up a spreadsheet with 20 or 30 possibilities, listing the advantages and disadvantages of each, but none were perfect. Many were simply too expensive for a small group to afford. Others were within our price range, but offered no permanent storage for our tools and equipment. Others still were too far away, or too concerned about the safety of the work we’d be doing.
We knew we’d have to get more organised, manage money, and get insurance. Our original (somewhat naïve) plan was to be somewhat of a free-for-all in terms of structure, where we were all equals and did everything as a group; but we were moving into a world of bank accounts and insurers who would want names and signatures on their forms. We formed a committee—President, Treasurer and myself as Secretary.
Around that time, one of our members offered us to team up with AdidoSrc, a group given space, pizza and booze by web development company Adido. We joined forces for three mid-week evenings in late 2013, before Adido suddenly pulled the plug—we were without a home almost as soon as we had found one.
We carried on looking. Soon we had free web hosting provided for us by Bitfolk and developed our new Wiki into a place for us to share ideas and coordinate. We wrote a Constitution and a Code of Conduct—we were getting serious.
2013 rolled into 2014, and the Constructorium strengthened its ties with the local Rep Rap Users’ Group, by then known as MakeBournemouth.
Local café and “creative hub” Makers Inc opened around this time, and MakeBournemouth started running some themed evenings there, where people came along to build a certain kit together. The Dorset Constructorium joined in for four events… before the cafe closed, and we were homeless once more.
In the ensuing downtime we expanded our web presence again, putting up a nicer-looking WordPress site to show visitors what we were all about, along with an online calendar for scheduling events, a Facebook page and a Twitter account.
Still holding out for a real space to call home, one of our members offered the services of their garden shed. After shifting out a decade’s worth of junk, we moved some of our tools in, and christened it the “Hack Shack”. Although it was and still is the closest we’d come to a hackerspace of our own, and we offered it four days a week for free, it wasn’t what our members had in mind; it never saw much use.
2014 become 2015, and our last hope came in the form of our local library. While MakeBournemouth contemplated going the big-budget route—allowing members to work on commercial projects, charging more, and affording a space at full commercial rates—the Constructorium tried our luck with the opposite, declaring ourselves strictly non-commercial and aiming for a discounted or free space by pushing the community/charity angle.
The library allowed us use of a back room to get started, and we had some excited conversations with the head librarian about the library getting 3D printers and our group running soldering and Raspberry Pi coding courses.
We had big plans, but by then attendance at our events was waning. Our meetings in the back room of the library averaged only four of us, and we never found the time or the confidence to offer courses. Our Facebook page attracted some interest, but we were never able to provide the organised experience that new visitors were expecting. Before long, we stopped meeting there, and for the third time in three years, we were without a place to meet.
And that, as they say, was that.
The IRC channel became abandoned, the mailing list posts dropped off to zero. The President moved to another town, and the Tresurer we haven’t heard from in some time. My job has got busier, and what little time and energy I had has dwindled further. Unless any member of the group wants to take it on from here, I think it’s about time to call the Dorset Constructorium to a close.
To all the members that made our group great over the years: thanks for the memories.
Back in the dim and distant past of my school days, Dreaming Awake was called “Dragon’s Claw” and was going to be a video game rather than a book. As far as I can tell from trawling the Internet Archive, not much was posted about it online, but for some reason today I remembered the design work we did on its skill system.
To my knowledge no game since has implemented something like this — probably because it’s not a particularly great idea — but it has a certain elegance to it so I thought it worth documenting.
I think we called the skill system “Chromatic”, or maybe “Prismatic”. Something like that. It was based on the Hue, Saturation and Luminance method of specifying colours on a video screen.
If you’ve ever used a paint program on a computer, you’ve almost certainly encountered this style of colour picker before. There are three axes to it: Hue, which specifies the colour, Saturation, which specifies how ‘colourful’ (as opposed to grey) the colour is, and Luminance, which specifies the shade of the colour from black to white. (Some systems use Value instead of Luminance, the difference is somewhat technical.)
In Dragon’s Claw’s system, the Hue of the colour represents the elemental association of the skill, along a continuum. So for example, Fire-based skills have a red hue (approximately 0 on the scale), Water-based skills have a blue hue (approximately 170 on a 0-255 scale). Something like the diagram below — there were more elements to fill up the remaining space, but I forget them now.
The Saturation of the colour represents the transition between physical abilities and magical abilities, with the physical ones being less colourful and the magical ones more so. For example, the magic spell “Fireball” might be bright red, while “Flaming Sword” is still the same hue but more physical, so has a lower saturation.
Luminance is a continuum between white and black, and represents the balance between “good” and “evil” abilities.
If I recall correctly, while abilities were balanced fairly well across the hue and saturation spectra, the majority of abilities clustered towards the centre of the luminance spectrum as the abilities themselves could rarely be said to be good or evil.
Each character had an innate “colour”, which represented their central position within the three-axis ability spectra. At level 1, a character would be able to use an ability only if it was within 1 integer of their colour on each spectrum. For example, if Rosa has a colour of Hue 0, Saturation 255, Luminance 128 (primary red), she can use any ability with Hue 255-1, Saturation 254-255, and Luminance 127-129. This is a pretty restricted set, although each character would have been designed such that they started with at least one ability.
As each character increases in level, the “sphere” around their innate colour expands, and if any new abilities fall within that sphere, the character learns that ability. By level 100, each character can use a sizeable proportion of available abilities, but never the complete set.
As the character uses abilities, their innate colour changes by a fraction towards the colour of the ability used. In this way, characters’ ability sets can be customised however the player wants, simply by practicing abilities in the right “direction”.
I always thought this was a pretty neat way of determining which characters can use which abilities, and the fact that characters get better at certain types of ability simply by practicing them or similar ones, is definitely appealing.
The concept of skills as a continuum also allowed for interesting benefits from the use of weapons. Swords, for example, might increase damage dealt by low-saturation (physical) skills, while staves might increase damage for high-saturation skills. A mace might benefit high-luminance (good) skills, while a dagger might benefit low-luminance (evil) skills.
There are a couple of big disadvantages, not least that we never found a good way of representing a 3D cube of colours to the player — we were limited by the ability of 2D screens and human eyes to see all three axes at the same time.
Certain areas of the spectrum were also rather sparse — certain hues, saturations and luminance ranges had a lot of abilities in them, while others had fewer, and characters with innate colours in those more sparse ranges would find themselves without as wide a choice of abilities as others.
The system also scales badly with level as originally designed. Each increase in level expanded the “sphere” of a character’s potential abilities in three axes at once, so an increase of n levels results in an increase of n3 volume. The result of this is that characters’ rate of picking up abilities becomes exponential. A logarithmic increase in sphere radius would have been a better idea to control this.
Alongside the difficulty in displaying the colour cube, it would also be difficult for players to discover the locations (i.e. colours) of new abilities that they may want. A lot of work would be needed in suggesting to the player which abilities they might want to practice, and what new things they would learn if they did.
It’s a little over a month until we are getting our first pet – a crested gecko. Joseph has decided that if it’s female it will be called “Scarlet”, and Eric has decided that if it’s male it will be called “Rimbaud” after the surrealist poet, partially because it is also a homonym of “Rambo”. I almost hope we get a female as it will be easier to explain.
In the mean time, we are getting our vivarium set up ready for our pet. We have just about everything we need, but managing the environment is a manual process — turning the lights on in the morning and off in the evening; maintaining heat and humidity.
Vivarium shown here with simulated occupant.
This is crying out to be an electronics project, so I’m going to make it one! In this post I’ve laid out my initial requirements and listed some suggested components. I’ll probably do one or two more covering the actual hardware build and software when the components arrive.
My requirements for the automated vivarium system are that it must:
The requirements to operate the lights at specific times of day (requiring a proper clock), to send emails, to use a camera and to send files to a computer all push the design towards one including a “proper” small form factor computer rather than a basic microcontroller. Due to my familiarity with the hardware I have chosen a Raspberry Pi for this system. The Model A should be sufficient for the system’s limited requirements.
The Raspberry Pi’s official camera modules are easy to use and have good performance due to dedicated processing on the Pi’s GPU. I have chosen the “NoIR” camera, which lacks the IR filter of the standard camera, to improve visibility of the gecko at night. No IR illuminator is proposed as this may interfere with the lizard’s sense of time or temperature regulation.
The proposed AM2315 thermometer and hygrometer module is comparatively expensive, but comes inside a tough enclosure with a wall mount and uses the standard I2C protocol, compared to the proprietary bit-banging protocols of the cheap sensors.
Relays will be used to switch the lights and heat mat power on and off. A breadboard will be mounted to a Raspberry Pi case to keep the hardware neat while allowing for easy extension in future.
Here’s my list of the components, along with links to buy them. All but one are available on Amazon in the UK; the thermometer/hygrometer seems to be an Adafruit special and will have to be imported from the US.
|Component||Choice||Price / GBP||Link|
|Computer||Raspberry Pi Model A+||18.00||Amazon UK|
|Wifi Dongle||Ralink RT5370||4.71||Amazon UK|
|GPIO Breakout||Pi Cobbler||10.00||Amazon UK|
|SD Card||Kingston 8GB||4.00||Amazon UK|
|Power Supply||Generic||6.00||Amazon UK|
|Case||Model A Case||4.49||Amazon UK|
|Camera||Raspberry Pi NoIR||19.13||Amazon UK|
|Suction cups||Generic||3.57||Amazon UK|
|Relay Board||Facilla 2-channel||1.13||Amazon UK|
|Enclosure for mains relay||Generic black ABS 150x80x50||5.90||Amazon UK|
|Enclosure glands||Generic M12x1.5||1.59||Amazon UK|
Stay tuned for build photos, schematics and source code once all the components arrive!
Update: It turns out the heat mat was bought with its own dedicated thermostat. With this in mind I’ve decided to ditch the timed control of the lights and use a standard mains plug timer instead. This will be easier for people to override if necessary, rather than depending on whatever software interface I provide.
Since the system is therefore not controlling anything I can ditch the relay board and the requirement to use a proper glanded enclosure to protect the 240V AC switching relay. It will still take photos, monitor temperature and humidity, display them on the web, and email on important events.
My SuccessWhale application has long supported both Twitter and Facebook social networks, despite both networks’ relatively developer-hostile stances. The worst offender by far was Twitter, with it’s 100,000 user limit that has deliberately crippled many third-party clients in order to drive users to the official website and app, which make money for Twitter through adverts. While I was never under any delusion that SuccessWhale would be popular enough to reach 100,000 users, it’s not a nice thing to have hanging over your head as a developer.
Facebook’s permissions policy, as I have ranted about before, also makes it difficult for third-party clients to deliver a useful service for their users. With the new requirement that apps migrate to API v2, they are adding the extra hassle of requiring all apps be reviewed by Facebook staff. This isn’t a problem itself — SuccessWhale has been through the somewhat scary process of manual review before when it was added to the Firefox Marketplace.
But Facebook has now snuck something extra into the notes for some of its permissions, each of which must now be manually approved as part of the review process. Into pretty much all the permissions that are fundamental for SuccessWhale, such as
Yep, this permission will be denied, as a matter of policy, to apps running on Android, iOS, web, desktop, and more.
So predictably, SuccessWhale failed its manual review and has been denied approval to use Facebook API v2.0 or above. As far as I can tell at this point, that means on May 1st all Facebook features of SuccessWhale will cease to function. Facebook, ever the proponent of the walled garden path down which Twitter has ventured as well, has struck another blow for increasing their profits and user lock-in at the expense of the open web that SuccessWhale depends on.
It’s a sad time for the web; the “web 2.0” of mashups and free access to data is slipping away with it. And though Facebook’s change does not kill off SuccessWhale and its kin outright, the future does not look rosy for us developers that believe users should be free to access a service in a way they prefer.
Playbulbs are colour LED lights sold by a company called Mipow. They come with an iOS and Android app that can set their colour and various patterns via Bluetooth. There’s no security on them whatsoever, so any nearby device can connect and change their colour. That seems pretty bad — especially when you consider that as well as the small “candle” style lights we have, they also sell room lighting versions that play music and can probably flash fast enough to trigger photosensitive epilepsy. Controlled by your neighbours!
Despite the security problem, this does have one advantage: it’s easy to get any other device controlling the Playbulb, not just a phone with their official app. Anything with a Bluetooth 4.0 Low Energy transceiver can easily control the Playbulb using tools like those provided by BlueZ under Linux, and the protocol is somewhat understood. This means it’s pretty easy to control a Playbulb programatically using the language of your choice.
Here’s a demonstration I knocked up this morning: mailcheck. This python script checks an IMAP mailbox at a defined interval, and will set the Playbulb colour to red if there are no unread messages, or green (with a brief flash) when you have unread mail. It was inspired by similar “ambient electronic devices” such as Nabaztag. Here it is in action:
It’s BSD-licenced open source, so if you have a Playbulb you want to have some fun with, please take my code and use it for your own ends!
Another year, another childrens’ toy with a Raspberry Pi needlessly attached to it.
Over the past few weeks, I’ve been taking one of my son’s old broken RC toys and turning it into something a bit more fun — by strapping a computer to it, naturally.
The result is the “All-Terrain Pi”, a robot which can be controlled by smartphone as if it were a racing game, or by using the kid-friendly Scratch programming language.
Programming in Scratch is possible too, recreating the 80s/90s Logo “Turtle” experience for a new generation. As with the smartphone interface there’s a Python program behind the scenes controlling the motor driver board, but this time it receives commands via Scratch’s “Remote Sensors Protocol”.
It didn’t take long for my son to get into controlling the robot, both with the game-like smartphone interface and using Scratch, which he has some experience with from school. (They start programming young now!) We took it to last weekend’s Constructorium hackerspace event at the library, where it was a big hit — by the end of the afternoon, he was teaching the grown-ups!
“Proud” is an understatement.
I’ve finished all the things I set out to achieve with this robot, in a total of only 20 hours or so. Thanks to a pre-made motor driver board and a Raspberry Pi camera fork of mjpg-streamer, some of the hardest bits of the project turned out to be very easy, so I’m very grateful to everyone whose work I’ve built upon to create this robot.
I’m hoping we might be allowed to take the robot into school and maybe hold a competition for the kids to write a program to steer it around an obstacle course; or something similar — to make programming more exciting by taking it off the computer screen and into the real world. If the teachers don’t let us do that, we might hook it up to the internet and have it controlled using redstone circuits on my son’s Minecraft server.
It’s no secret that the current state of my SuccessWhale social network client is not a good one. It currently exists in three forms:
SuccessWhale v3.0 web interface
Very occasionally, I get the motivation to do something about SuccessWhale. It feels bad to leave it in its current “limbo” state where there isn’t really a version that works and is properly maintained. I use SuccessWhale every day, so at least there’s the dogfooding aspect, but “it works well enough for me” is far from “it’s something other people would want to use”. And my friend Fae produces the excellent OnoSendai Android client that uses SuccessWhale, so I have some sort of responsibility to him to keep SuccessWhale going.
But there’s a hell of a lot of reasons why I would rather not.
For now, SuccessWhale stays alive. Twitter and Facebook are what I’m stuck with as the only sensible way of communicating with many of my friends and family, and SuccessWhale helps me avoid the worst features of their interfaces — their cryptically-curated feeds, in-line adverts and one-feed-at-a-time pages. That, plus a vague sense of responsibility to my users, are what keeps it around.
When the day comes that I can jetission Twitter and Facebook from my life without missing them, it will be SuccessWhale whose loss I mourn. Like many projects before it, its user count will fall to zero and it will slowly start to fade from the internet.
One day, I’ll be sad that I made a thing that is no more. But right now, all I feel for the thing is the frustration that developing it is fighting a losing battle that has no end in sight.
Over the weekend, my friend Alex visited us and brought his quadcopter in tow. I’ve bee trying my best to dump ideas on the internet and avoid buying my own extremely expensive remote control toys, but I can see the day I give in getting closer.
Here’s my flight over Bournemouth beach, flown as cautiously as you might expect given that I had £500 of someone else’s money in the air!
There are a whole host of decisions involved with starting a new software project. What’s my target audience? What language shall I write it in? Which libraries shall I use? And of course, “What shall I call it?”
So picking a name for an open-source project or tool is IMPOSSIBLE it seems…
— Mark Embling (@markembling) April 22, 2013
For anyone looking to give their new project a unique name, there’s an annoying process to go through of searching for each idea to see if something already exists by that name. Linux packages need to have unique names, as do SourceForge projects, Ruby Gems and projects on many other distribution systems.
As of 4pm yesterday, there was no simple way of querying all these repositories and package management systems together, to see if your chosen name was already taken by someone else.
So at 8pm I sat down to code. And by 11pm, there was a way to do exactly that.
— Ian Renton (@tsuki_chama) April 22, 2013
Meet CICI, or “Can I Call it…?”
CICI is a simple website. You give it a name you would like to use for your project, it checks against a bunch of services, and tells you if your name is unique – i.e., you can call it that – or not.
Currently, CICI looks up information on packages and projects using Github, SourceForge, Ruby Gems, PyPI, Maven, Debian and Fedora, but it’s easy to add more. CICI itself is a simple Ruby script (full of ugly hacks, as is befitting for a program that I knocked together in a few hours), which you can download and contribute to on GitHub. It’s all BSD-licenced.
Of course, you can play with CICI on the web right here:
As we have also discovered, typing random words into the search box to see what it finds is surprisingly addictive… See what odd (or even useful) things you can find on CICI, and good luck with your new projects – whatever name you end up giving them!
It’s no secret that, since the launch of version 2.0 back in July of 2011, my SuccessWhale social network client has stagnated somewhat. It had reached that point at which it did everything that I needed it to do, and so my enthusiasm for updating it kind of disappeared.
Well, no longer. Twitter discontinued TweetDeck, the only Android client that merged Twitter notifications and Facebook feeds without sucking. At the same time it discontinued TweetDeck’s desktop client, and removed Facebook support from the web-based client.
That really sucks.
And that’s where SuccessWhale comes in.
I’m no longer content with the ways in which I interact with Twitter and Facebook, particularly on mobile devices, so we’re going to fix it.
SuccessWhale began as a “my first PHP application” kind of affair, and right now it still is. The code behind it is an ugly mash of model, view and controller without a decent structure. SuccessWhale version 3 will be rebuilt from the ground up with proper design principles behind it.
Even better, haku is making an Android client called OnoSendai which will feature the combined feed columns that are SuccessWhale’s major feature. We will bring TweetDeck’s feature set back to Android with a lot more besides, offering the users the ability to mix together the feeds in their social network client like never before.
And to prevent our software going the way of TweetDeck – being bought up and eventually scrapped – SuccessWhale and OnoSendai are open source software. A version of SuccessWhale’s API, operating on the main database at sw.onlydreaming.net, will be open for anyone to use and build clients for. SuccessWhale is released under the BSD 2-clause licence and OnoSendai under the Apache 2.0 licence, meaning that even if we were to be bought out, anyone on the web could simply grab our source code and run their own SuccessWhale.
We’re bringing TweetDeck’s features back to Android and to the web. We’re making SuccessWhale an application to be proud of. We’re free, we’re open, and we’re Twitter-proof.
I’ve since relocated all my web stuff to Dreamhost, taking advantage of their unlimited bandwidth offering to plow through 10 GB and more a month. But now I’m coming up against the last remaining limit of my shared hosting – memory usage.
Both Westminster Hubble, which constantly crawls MPs’ social networks and RSS feeds, and an increasingly complex SuccessWhale, churn through a ton of memory. I don’t have a nice scary graph for this one, but at peak times, I’d estimate that my web server kills over half my PHP processes due to excess memory use. That means Only Dreaming basically goes down, while SuccessWhale throws errors around if it even loads at all.
It looks like I’m left taking the expensive plunge of moving my hosting to a VPS rather than a shared solution, which is a jump I’m nervous to make, especially since none of my web properties make me any money. Most worrying of all is that VPS prices tend to vary by available memory, and I don’t actually know how much memory all my stuff would take up if it were allowed free rein. And nor do I have any way of finding out, bar jumping ship to a VPS and taking advantage of free trial weeks.
So, dear lazyweb, do you have any experience with this sort of thing? And can anyone reccommend a good (cheap!) VPS host that fulfils the following criteria:
I’ve been recommended linode by a friend which seems great for tinkering, though the price scales up rapidly with RAM use and I’m not sure I want to deal with the hassle of setting up Apache, MySQL etc. by myself. And there’s Dreamhost’s own offering, which would be virtually zero-hassle to switch to, but probably isn’t the cheapest around.
So, citizens of the interweb, I seek your advice!
The big changes between version 1.1.2 and 2.0 are:
You can see a screenshot of it in action below:
I would particularly like to thank Alex Hutter, Hugo Day, Erica Renton and Rg Enzon, whose help in finding bugs and suggesting new features has been instrumental in bringing SuccessWhale up to version 2.0 today.
It’s a site that helps you keep track of your promises day-to-day, giving you a pretty display of which promises you’ve kept when, and letting you compete against your Twitter-using friends to be the best at keeping your daily promises!
For now, you can find Daily Promise at http://dp.onlydreaming.net.
I’ll make the same deal as I made with Dynamic Democracy, but doubling the number so that I can be more sure of it taking off, and that’s the following:
At the moment the site does everything I want it to do, and it’s hosted on a subdomain of my main website, which I have no problem with. What I would like to do is give it its own domain, and start implementing feature requests that people send in. So that I don’t end up spending money on something that’s going to die off quickly, the deal is this: When it gets 20 active users, it gets a domain and some TLC. If it doesn’t make it to that point, it stays like it is.
So if you’d like to help me make something of this site, please start using it, and show it to any of your Twitter-using friends who might need a little help getting healthy, keeping fit or any other goal that Daily Promise can help them with!
After a couple of days and one frantic family-free morning, Daily Promise is getting near completion. Here’s what’s new since last time.
Here’s the Friends page – again, almost no deviation from the original design sketch. The friends page pulls in the list of people that you follow on Twitter, matches it up against Daily Promise’s user list, and if any match, they’re your Daily Promise friends! They’re simply displayed in alphabetical order, along with a summary of their performance. Invisible users (see later) don’t appear, even to their friends.
Nicer User Pages
Top Users Widget
Spam your Friends!
Twitter integration now includes boxes suggesting Tweets you might like to make after each significant activity. Just as promised in the “How does it work” graphic, Daily Promise never posts to your Twitter account without you deliberately clicking a “Tweet” button each and every time. Do no evil!
Behind the Scenes
A lot of other stuff has changed in the last few days that isn’t immediately obvious to users:
This all brings me to the slightly worrying conclusion that Daily Promise is damn near finished. So, where do we go from here? I’ll have a few more days of bug-fixing and implementing features that people request, and then it’s difficult decision time:
This has been a fun project for the last week or so – does it deserve a domain and advertising, or shall I let it quietly die?
Despite the lack of response to my earlier post, in which I floated my design concepts for “Daily Promise”, boredom won out in the end and I started coding anyway.
It’s now coming together, and all bar the Twitter-integrated social aspects are largely complete. Here’s how it’s developed:
The social side – top users, etc. – still isn’t implemented, but there’s a reasonable-looking homepage in there. The main body is taken up with a short description and a big graphic explaining how the site works. Side-bar widgets provide the Twitter login and alternative login (bypassing
twitter.com). The site now has a proper name, Daily Promise, and with it a logo and style that is reflected throughout.
Set Up Goals (“Manage”)
The “Manage” page has remained almost exactly faithful to the design. New promises can be created, old ones deactivated and deactivated ones can be activated again. A Tweet box appears for the user to announce their new promise, if desired.
Daily Performance (“Enter”)
Again, there’s not a lot of difference here between the design and the reality. Each promise has a yes/no choice, and after completing a day’s entries, Tweet boxes appear for the user to let their friends know about their successes and failures. “Winning streaks” aren’t yet implemented.
Performance Log (“View”)
There’s no ability to scroll through your history yet, but the default display shows 4 weeks (which scroll if necessary). Just as in the design drawings, the history table is followed by a text summary of how the user is doing.
The “View” page also, with a few additions, becomes a user’s profile page, which is accessible to other users.
Here you can set your password for the alternative login, and delete your account. It’s exactly as dull as it sounds.
That’s my big job for the next few days! It doesn’t exist yet, but it’s now my top priority.
Current flavour of the month of some of the geek crowd, “Health Month”, is a social network of sorts on which users compete to achieve certain health-related goals. Each month, each member sets a number of goals for themselves to achieve. Its core mechanic is health points – you start with 10, lose one every time you fail to meet a goal, and players who perform well can heal you.
I’m enjoying my use of the site with three goals this month, but I’d like to step it up and set lots. Unfortunately, having more than three goals costs money. (Not that I think the site’s owners don’t have a right to charge, but it can be a deterrent to users such as myself.) It also currently only allows two “custom” rules per month – beyond that, you have to stick with the pre-defined ones.
Another social health site is Tweet What You Eat, on which users tweet their food intake and have the site, or the community, calculate statistics such as their calorie intake.
Over my lunch hour, I’ve come up with some sketches for a site that sits somewhere between the two. It takes Health Month’s goals mechanic, opens it up and removes some of the social aspects that in my opinion Health Month doesn’t implement all that well. It also drifts closer to Tweet What You Eat, in that rather than being its own service it piggybacks of Twitter for its social side.
At the moment this is just a fun concept I’m toying with – I don’t really have the time to make it at the moment, I doubt the space between Health Month and Tweet What You Eat is wide enough to make a new site popular, and I feel a little guilty about thanking Health Month for the enjoyment I’ve had by becoming its competitor.
In the notes below it’s dubbed healthi.ly, though as that domain is parked, it’s come to be known as “Daily Promise” instead.
The home page would largely be a “log in / register” affair, possibly also showcasing successful and popular users in a side-bar (not shown). Big banner text explains the rough concept, with a “read more” link to a full “About” page. On the registration side, we make it clear exactly what Daily Promise does and doesn’t do with access to your Twitter account.
Set Up Goals
The main setup page is where you set your goals. Users can set any (reasonable) number of goals, they can drop and resurrect old ones, and add new ones, at any time. Performance against all the goals is tracked and visible on this page. Adding new goals and dropping old ones can be tweeted, but as with every tweet opportunity, the user is presented with an @Anywhere box that they can freely edit and can choose not to tweet as easily as they can choose to tweet. The tweet links to the list of goals on their profile.
Once goals are set, the user logs in each day (and can fill in past gaps) with whether or not they have met each goal. Each day’s entry presents some brief statistics, and you get more stats on the week after filling in Sunday’s performance. Very good or very bad performance suggests a Tweet that a user might like to make. The tweet links to their performance log on their profile.
This is a user’s main screen. It displays a chart of passes and fails for the last month or so as green (pass), red (fail) or grey (goal not active) squares. Below the chart, more detailed stats are presented, as well as an encouraging text summary of how the user is doing.
Most of the core settings such as username, display name, avatar and bio are handled by Twitter. Daily Promise’s settings probably boil down to privacy (stop me being searchable, delete my account, etc.) and removing annoyances (always tweet on condition x, never tweet on condition y, etc. – all of which have an “ask me” setting by default).
The user’s “following” list from Twitter is used to generate their list of Daily Promise friends. Avatars, usernames and Daily Promise performance summaries are displayed here. Clicking through to a user’s profile shows the “performance log” page, topped with name / avatar / bio / etc.
So, and interesting idea, or an appalling one? Would you use this? Should I get off my arse and code? Should I have finished the last six things I started before prototyping something new? Your thoughts are, as always, appreciated.
The distinction between surface ships and submarines in Sea Battle has turned out to be a more thorny issue than I originally imagined.
The original plan was to have two classes of vessel, based on their hull types – ship or submarine – and weapons that could hit ships, submarines, or both. A future update could also have included aircraft “hulls”. However, the more I think about the game balance issues, the less I’m convinced that this is a good decision with the tech tree and playing field size that Sea Battle currently has.
Sea Battle’s tech tree, as it currently exists, has four straight “trees” with 10 items in each. By and large, each component that you research is better than its predecessor. (Later hulls are heavier and take longer to build, so small hulls are still useful. However, you would rarely want to choose anything other than the best weapon, engine and radar that is available to you.) Combined with the small playing field, this makes for a fast-paced game of a few minutes, with each player researching and churning out ships constantly to gain the upper hand.
There are a number of reasons why the current tech tree is inappropriate for submarines. Firstly, the weapons that a submarine could have: there’s only two. The Sting Ray torpedo (weapon 8) and Tomahawk missile (weapon 9) are the only weapons appropriate to be fired from a submarine. This would make rushing down the hull tree to submarines pointless unless you’d already reached near the end of the weapons tree – and in most games, you don’t even get that far.
It also creates a UI complication, in that currently, any combination of hull and weapon is permissible. Submarine-appropriate weapons would break that behaviour.
There’s an issue with anti-submarine weapons too. Again, only two (Depth Charge (6) and Sting Ray (8)) are appropriate for use against submarines. But since a viable submarine build wouldn’t exist until Hull 6 + Weapon 8, they would only exist in the late game, at which point Depth Charges just can’t hold their own against other weapons – so why have them at all?
To abuse game theory, the logical choice is for players to build Depth Charge ships when they become available, then hold them in reserve as insurance against their opponent building submarines. But if you see your opponent stocking up on Depth Charge ships, you might as well not bother building subs and just go for better weapons and radar instead. Whoever commits to a strategy first ends up on the losing end.
To cure these problems, perhaps we need to take another lesson from Warzone 2100’s book and have separate tech trees for different weapon types. So rather than one tree of 10 weapons, we have two trees for anti-ship and anti-sub. (And potentially anti-air later.) If we’re going down this route we ought to have different hull trees for ships and subs too. But at this point it’s turning into a rather different game – a slower, more traditional rock-paper-scissors RTS. But these games benefit from larger playing fields, varied terrain and squad-based combat – none of which Sea Battle is particularly well suited to in its current form.
So the question stands: Do I expand Sea Battle significantly to include this extra complexity, on the understanding that I would probably need to rewrite it in something other than Processing and that may consign it to the pile of “projects I lost interest in”, or do I just ignore the issue and for the sake of simplicity not treat submarine hulls as any different from ships?
First things first, my failings: CPU use and mouse sensitivity are still not fixed. I’m now having to re-render more of the window on each refresh than before, so if anything they might be slightly worse.
On the Facebook thread, Scott and Mark mentioned an AI issue in that a suitably scary player ship, when parked close to but slightly off to one side of the enemy base, will be ignored by enemy ships in favour of attacking the player base instead – even when they have no hope of destroying the player’s base before their own is destroyed. As far as I know that issue is still there, though improved enemy research and build AI should mean the enemy is pumping out ships just as scary as yours.
On to the new features:
And bug fixes / tweaks:
Still to come:
If you’d like a good strategy for beating the game at this point, I recommend you begin by keeping your build queue about 3-4 ships full, building the best thing you can at any point. Research-wise, rush down the weapons tree as far as Harpoon missiles, throwing in a couple of hulls and radars. Avoid engines for now. As soon as you have Frigates with Harpoons and Radar Mk 4, keep building them until you’ve fended off all the enemies near your base and you have a fleet of 15-20 of them, then move them all right up to the enemy base. With that fleet you should be able to destroy the base before the ships they build wear yours down too much.
Today’s release reduces the target frame rate from 60 to 30 frames per second, in an attempt to alleviate the CPU hogging reported by aefaradien in the previous post’s comments section. As I said in the comments, it’s not an issue I see on every machine, so I’d be grateful if any testers could tell me what PC setup they have, and how much CPU power the game takes up.
Today’s version also fixes the spinning ships bug that just about everyone reported. What it doesn’t do is make mouse clicks any more responsive, which is annoying me too. Please bear with it for today, I’ll see if I can work out how to deal with that soon.
Mostly this release is about new features. Sea Battle now has:
The only real bit of functionality that’s still missing is the research / build options. Currently, clicking the Build button produces a ship of a predefined configuration – you can’t change that config or research better ones. The AI builds random ships up to and including as powerful as your default one, and has a reasonable amount of ‘thought delay’ to its actions, meaning that you can achieve victory fairly easily. (Just fill up the build queue and send every ship North as soon as it’s built – you’ll lose a few, but enough should survive to destroy the enemy base.)
Note: this blog post is old, and the game now has more functionality than is described here. The next blog post in the sequence is here.
Nearly a month ago now, I blogged some sketches and ideas for a game I felt like writing. masterofwalri made a passing reference to Processing in his comment, and having heard people mention it in the past, I figured I should check it out.
I’m very, very glad I did.
It neatly deals with the issue of what I should develop for. The comments were leading me down the Java path anyway, but Processing’s two-click export to Applet and bundles for Windows, Linux and Mac OS sealed the deal. And it’s easy to program in too – it’s clear that it’s beginner-oriented, but it’s also ideal for simple games like this as it simply removes all the starting faff, like sorting out
TimerTasks and all the rest. Time will tell if Processing over-simplifies things and stops me doing something I want to do, but for now it is excelling at the main task of high-level programming languages – reducing the amount of brain overhead I need to allocate in order to talk to the computer.
One lunchtime has produced 270 lines of code – which already includes the game area of the GUI, controllable player ships, and the beginnings of AI for the enemy ships.
Note: this blog post is old, and the game now has more functionality than is described here. The next blog post in the sequence is here.
Currently there’s no real gameplay – you can’t build, and ships can’t shoot or be damaged. You can move your ships (starting at the bottom of the screen) around, and the AI ship will hunt yours. Click on a ship to select it (blue circle), then click elsewhere to set its destination. Red lines, when they appear, show when ships would be shooting.
The next block of code will give the ships customised gear, health points, and the ability to attack and sink others. With that will probably come attack animations, which with my lack of skill in that department, will take a while. After that, damageable bases and win/lose conditions, then the build/research system. Finally, graphics tweaks, AI improvements and game balancing will finish it off.
More bloggery will appear once more coding occurs!
The sudden proliferation of peoples’ syndicated tweets from sources such as Foursquare and Fallen London annoys me far more than it should. Any more sensible old grouch would pick up his pipe, don slippers and write a strongly-worded letter to the local newspaper about how this ‘checking in’ business is corrupting society.
Instead, I made my Twitter client block them. Also, you can now do it too!
SuccessWhale users will now see a link at the top-right of the interface called ‘Manage Banned Phrases’. Clicking it will take you to a page where you can specify a semicolon-separated list of things you don’t want to see, such as “
4sq.com;fallenlondon.com;bieber”. Once confirmed, any tweets in any timeline that are sucky enough to contain one of these phrases will be hidden from your view.
Twitter: now 12% less full of shite!
An extra feature has been rolled into this release, which is the ‘Reply All’ button. It only appears where two or more people are having a conversation (three or more if you’re included too). Clicking on it starts a reply to everyone mentioned, not just the tweet’s originator. So if @Alice is talking to @Bob, and you click ‘Reply All’ on one of her tweets, your entry box will then read “@Alice @Bob”.
So that’s version 1.1. Share and enjoy!
SuccessWhale is a free, open, multi-platform web-based Twitter client. It’s hosted at sw.onlydreaming.net, and you can find out more about SuccessWhale here. It’s GPL-licenced, so you can download yourself a copy too if you want one.
The vast majority of user-reported bugs and requested features on “a thousand words” have now been sorted out. As requested by my co-conspirator Eric, we now have an ‘adult content’ filter based on a date of birth field in users’ profiles, and a ‘report’ button to bring problematic stories and pictures to the attention of the moderators. There’s also a DeviantArt-style “request critique” option to let users know what kind of comments you’re looking for.
Timestamps have been fixed, “no stars yet” ratings introduced, and text field policies such as “mustn’t be empty” have been added across the site. A few rendering issues in IE have been sorted out, so it now looks much the same across all platforms.
The biggest change is unfortunately something most of you will never see – the moderator console. Picture submissions and reported stories/pictures now sit in queues that can be dealt with by moderators. An item entering a queue triggers an e-mail to all mods, who are invited to review it and make changes as appropriate. Once changes are made, the affected users are then e-mailed to let them know what happened (and in the case of reported items, to give them a chance to challenge it).
There’s one major feature request that’s not yet been implemented: file uploads. Once in the system this would allow users to submit pictures from their hard drives rather than from the web by URL, and would allow moderators to copy URL-linked pictures to the site to avoid hotlinking. (At present we don’t hotlink, but we do therefore have to copy pictures to the site manually using FTP.) It could also allow users to use a non-Gravatar picture for their profile.
Depending on how things go, that may or may not be ready by tomorrow night. On Saturday morning I jet off to sunny Saudi Arabia, so any changes not made by then are going to remain unmade for a while. From that point it’s in Eric’s capable hands as to whether she wants to release the site or not. Even if the site does advance to release status, I’m still taking bug reports (they’ll sit in my inbox until I get back), so keep on letting me know what’s broken and what you’d like to see added!
“a thousand words” has now reached a stage where every feature that I give a damn about is implemented. Thus, we’re opening it up to a limited beta test to iron out the wrinkles and get a list of any features potential users would like to see us launch with. If you’re bored or simply have a love of breaking other people’s shit, head along to http://athousandwords.org.uk and see what hell you can raise. As the Big Red Box Text warns you, really don’t submit any work of fiction you care about, just in case some kind soul finds an SQL injection vulnerability and trashes the database.
Since last time I bored the hell out of you all, voting and commenting has been implemented, registration has been fixed, filtering HTML tags from submissions has been added, as has a word count and the picture selector on story submission. There’s been a bunch of behind-the-scenes tweaks to improve security too.
The one feature that Eric definitely wants is a way to mark stories according to their content. We could do this in several ways – I would prefer, if anything, to just have a “not for kids” option on each post and a Date of Birth field associated with user accounts, so we can hide stories as required. Other options include a range of ratings (U, PG, 12, 15, 18…) or tags for certain content (violence, sex, language) so people can avoid whatever they’re picky about.
This probably ought to come with a Report button so that users can report incorrectly rated stories, and I would add a similar feature to report pictures. (Picture submissions are moderated, so Goatse isn’t going to make it through anyway, but the mod team might miss subtler things like licencing terms and copyright infringement.)
At that point, all that’s left on my list is the admin interface and anything that users suggest during this beta. Hopefully we’ll be ready to launch by the time I depart for sandier shores at the end of the week!
A few days’ laziness (by which I mean a few days’ Starcraft) have passed with not much work being done on “a thousand words”. That came to an end tonight, with a productive evening resulting in a working profile system so that users can now add and display personal information, change their registered e-mail address and password, etc.
There’s now a database backend for the voting and commenting systems, which will be complemented by their GUI pages tomorrow night.
Once that’s done, that’s the last of the main functions out of the way and we’re basically down to tweaks. I think we ought to, in no particular order:
At that point, I think it should be ready for open beta. Hopefully we can get it all done within a week, before I depart for internet-less shores!
Another day, another bunch of functionality added to a thousand words. With the main public-facing interfaces largely complete, I have moved on to the guts of the site’s user interaction. The site now has working, but ugly, implementations of:
A story edit/delete interface is my next task, and once that’s done, the core functionality (excluding any user profile-related code) will be largely finished. After that there’ll be a period of testing and improving the interfaces of the new functions, before I put a call out for a couple of willing guinea pigs to try and break the site for me! If anyone out there is expecting to be really bored sometime this week, let me know!
With the main browsing UI for a thousand words up and running, it’s time to bore the world with more pointless trivia before moving on. Today: design sketches!
Pretty much every software project I undertake these days begins with a sketch of the user interface and an initial structure for the database. Labouring under the cruel ‘no whiteboard’ conditions at home (maybe I should get one?), I drew these out on paper. Passing the UI sketch over to Eric after about 5 minutes’ work, she described it as “awesome”. I think that’s the first time that’s ever happened; the general response at work is along the lines of “but where are you going to put giant-ugly-element-X that I’ve just thought of and wasn’t in the spec?”. So that was that, and I’ve coded it up pretty much as it was on paper.
The database hasn’t changed much from the original design yet, but it will have to soon – as designed, the vote (‘stars’) system doesn’t record each user’s vote on each story, so it can’t support users changing their vote. Sometime during development I’ll have to devote a few hours to figure out the best way of handling it, though that probably comes down to a few minutes as someone on Stack Overflow has inevitably asked about it already.
Next up on a thousand words is coding the first few forms that will allow users to register and log in, submit photos and submit stories. That should be done within the next few days, and will allow me to play with actually changing the contents of the database, rather than just showing views of it.
Somehow unable to cope with actually having free time of an evening, I have taken on yet another project which will doubtless push me deeper into the dark, untamed wilds of the internet, the land stalked only by the mysterious beast known as the “web developer”.
I’ll be coding up this site in my spare time over the next few weeks, and you can check out my current progress on the live site at a thousand words. Currently, the database design is done and I’m partway through the UI of what will be the main page. My todo list is roughly:
As I go I’ll be posting updates and hopefully-interesting insights here, and you can always check the site at athousandwords.org.uk to see how I’m getting on.
Back in April, the Digital Economy Bill was rushed through the wash-up procedure of the outgoing government without the due debate and consideration that I and others believe such a far-reaching bill deserved. My disillusionment with the government decision-making process over the following week led me to set up and announce a new site, called “Dynamic Democracy”. It was an experiment to see what would be discussed if everyone was involved – on an anonymous basis – rather than just our elected representatives that often do not do a good job of representing us anyway.
The site allowed all users to create and comment on ‘Bills’, encapsulated ideas or laws that they would be pushing for if they were in power. Registering gave users the ability to vote bills (and comments) up and down, leading to a list of highest-ranked bills that represented the users’ favourite potential policies.
Dynamic Democracy saw little success, possibly because writing a full, well-thought-out bill represented significant effort that a casual browser would be unlikely to commit. ‘Karma’, the point system that aimed to encourage users to submit bills and comments, did not prove to be a good enough incentive as there were so few users to compete with and no direct reward was ever implemented for reaching high karma levels.
What the site did bring, however, was a number of enquiries from like-minded individuals all over the world, keen to discuss the ideas behind the site and whether or not something like Dynamic Democracy could ever be implemented as a real government policy-making tool. One of the more notable contacts, Denny de la Haye, stood as a candidate for Hackney South and Shoreditch in the general election and promised to implement a crowd-sourced voting system similar to Dynamic Democracy for his constituents to voice their opinions in Parliament through him. (Denny, who sadly did not win his seat, now represents the UK arm of political party DemoEx.)
I have decided that today is the day to close the Dynamic Democracy experiment, because today the UK government announced their “Your Freedom” website. While largely focussed on repealing or changing laws rather than the complete freedom to suggest anything you like, Your Freedom is certainly in the same vein as Dynamic Democracy, with the crucial extra feature that is endorsed and used by our government and thus ideas proposed there stand at least some chance of making it into official government policy.
Time will tell whether that really happens, or if like the No. 10 Petitions site, suggestions will be responded to with an e-mail from the Prime Minister’s office explaining why thousands of users are all wrong. But I do still hold out hope.
Did Dynamic Democracy influence the government in their decision to create Your Freedom? Almost certainly not. As my discussions with visitors to the site have shown, I am far from the only person to have come up with this idea, and neither am I the only one to have coded up a website around it. No – this is simply an idea whose time has come. A vast gulf exists between Westminster and the world outside, just as it always has, but these days the public are coming to question why that is and if we can do something to correct it. And nowhere is the desire to bridge that gulf stronger than among the tech-savvy youth that have the drive and the ability to use the internet to that end. Sites like these will come and go a hundred times over the coming years and decades, and slowly but surely we’ll reshape our government into what we want it to be.
So to everyone who contributed to Dynamic Democracy: thank you, and goodbye.
If you’d like to contact me about Dynamic Democracy (or anything else), you can still do that via email. If you’d like to help get the Digital Economy Act repealed, please vote up and comment on one of these ideas on Your Freedom. If anyone would like use of dynamicdemocracy.org.uk until my ownership expires in 2012, let me know. Stay tuned for the announcement of another project that bridges politics and the internet in the next few weeks.
I’ve been an advocate of opening up our democracy and involving the public in government decision-making for some time, without doing anything particularly concrete about it besides placing my vote. The Digital Economy Bill fiasco showed us that, really, we’re not involved with the day-to-day workings of government at all, and born of that is this experiment.
I’d like to know what we, the people, think our government should be talking about. I’d like us ordinary people to submit our ideas, vote on other people’s ideas, and come up with some idea of what we really care about. And so here we are:
This is all very experimental at the moment – please sign up, post ideas, vote on other people’s ideas, and if it proves popular I’ll take it on as a permanent project. Let’s do this!
For the last few days I’ve been working on a simple web-based Twitter client, to fill the void between the simplicity of Twitter’s own web interface and the broken-in-IE6 complexity of BeTwittered and Seesmic Desktop’s web interface.
It’s still under heavy development, and there are probably a ton of bugs and missing useful features. Please give it a try and let me know what you think. Bug reports are more than welcome!
The source code is licenced under the GNU GPL v3.
Update: Due to a move to the proper OAuth API, the software could no longer continue to be called FailWhale, as someone’s already written a Twitter app with that name! Thus, until I or someone else comes up with a good idea, it’s called SuccessWhale.