http://stuffthathappens.com/blog/2008/03/05/simplicity/
http://stuffthathappens.com/blog/2008/03/05/simplicity/I was looking around for some alternatives to Basecamp, and was pretty surprised to see that there are a ton of alternatives out there. So naturally a list is the way forward.
No recommendations yet, and not all of these are Basecamp replacments - Harvest and ClockingIt, for example, could be seen as complimentary.
- Goplan
- Unfuddle
- OnStage
- Harvest (time tracking and invoicing)
- TeamWorkLive
- ActionThis
- 5pm
- DeskAway
- Collabtrak
- ActiveCollab (self hosted)
- ProjectPier (fork of older version of ActiveCollab, selfhosted, opensource)
- ClockingIt (timetracking, opensource)
- Lighthouse
- Copper
- Wrike
- Intervals
- Central Desktop
- Huddle
Technorati Tags: basecamp, projectmanagement
As is the case in all conferences, the true value is always in the people you meet,rather than the conference itself, and I've been having a blast hanging out with some irreverently like-minded people from down-under - Adrian Copley (Copley Communications), Anna Kominik (Ideas Shop) and Amanda Boland Curran (Acid), - who are a lot of fun, as well as being smart and experienced comms professionals. What's especially pleasing is that they're switched on to the way that social media is changing and cascading through the communications sector - and not in a lemming-like follow the herd way, but with an appreciation of how social tools can benefit an organisation if handled properly.
A few margaritas have been drunk, and lots of interesting conversations have been had. Their english isn't bad, and I've been pleased that we've been able to communicate pretty well, only occasionally needing to resort to sign language to get the message across ;-)
I've also been roped in (obligatory cattle and cowboys reference, seeing that I'm Texas) to a panel this afternoon organised by the San Antonio chapter, talking about International Communications Trends. Needless to say, I'm going to spend my bits talking about social media!
Looking forward to an interesting few days, as well as seeing a bit of San Antonio, a town I visited for the first and only time 20 years ago.
That is what I found this evening. I believe that some one managed to issue a password reset command to my account and then somehow logged in and reset my password essentially owning my data.and this
Seriously scary stuff, and this for a guy who is pretty technical and also highly connected with people who can help.update: my account just got hijacked again, minutes ago. Also so did my GMail account.
I have no idea WTF is going on here. I have only used one computer this entire time.
Alarmed by this - I had a quick check of my own situation - my stuff is pretty well backed up - to a NAS point for local backup, and then to Amazon's S3 via JungleDisk. My GMail is regularly downloaded to Thunderbird via IMAP. But the thought of someone getting access to my Google account makes me break out in a cold sweat.
So - what do I do to make sure I'm as secure as I can be ?
- Check my Google password is long and strong. (Yes - 20 chars, mix of letters, digits and symbols)
- Vow never to connect to anything sensitive 'in the clear', especially over public WiFi.
- When sensitive information (especiallly login details) is to be exchanged always connect via https (https:/mail.google.com/mail).Check your desktop and especially your laptop that this is the case. Check your bookmarks.
- Set up an account with a VPN provider to use to connect through (and make sure you use it)
- Use something like a 3G modem to bypass public wifi competely (but still connect via https). I have one (from Three), and it's great as a ADSL backup and also for travelling - no more £5.95 for 1 hour's unsecure internet access for me !
- Make sure you have a personal
question that is non-obvious (don't do date of birth, mother's maiden
name etc). If your provider doesn't allow you to have a non-obvious
question, then change, or don't store anything of value in there.
- Make
sure you are backed up, and that your backups work. I know this is one
of those things that everyone says, but really, do it. You have no idea
how much of a comfort it is when you know that all your really
important info is backed up in a number of different places. JungleDisk is
pretty amazing for letting you just set and forget - I back up all my
pictures, and documents there, as well as my partner's docs - and
Jungledisk is smart enough to only upload files that are new or changed
(and you can pay $1 per month to activate a service to only upload
diffs to large files).
- Get a good virusscanner, malware
protector and firewall. Keyloggers are another source of danger - I
hear a lot of reports of kids playing WoW who have had their accounts
hacked via keyloggers (from programs they've downloaded). Set your
firewall to alert you on any new outbound connections, and don't allow
anything you don't recognise through.
Movable Type's PublishQueue has some memory leakage, and running in daemon mode (for quicker response to rebuilds) highlights this problem.
So the solution (where solution = not particularly pretty workaround) is to run PQ under daemontools as per this writeup by Byrne Reese. This sets up a monitor which constantly scans for the PQ job and restarts it if it's not there.
Then create a cronjob that kills PQ every hour or so, using pkill
*/15 * * * * pkill -SIGINT run-periodic
So, in this example, the cronjob runs pkill every 15 minutes and kills any processes that contain 'run-periodic' in their name (run-periodic-tasks is the perl script that runs the PublishQueue workers).
The svscan process (part of the daemontools suite) notices instantly (within milliseconds) that the PQ task isn't running, and starts it up and memory is back to normal.
Now, this obviously isn't ideal, but the 6A guys (and some of the more Perl aware parts members (!) of the community) are well aware of the problem, and are looking at how to fix the leaky bits, as well as make the whole thing run better and faster. In the meantime, this is working well for me.
[Update - 6A have acknowledged the memory leaks issue in the latest MT 4.1 release notes and have advised that PublishQueue not be run in daemon mode, or with FastCGI - both of which are fairly essential. My workaround is even more valid now.
Also note the addition of the SIGINT signal to the pkill command - this is a less forceful shutdown and was recommended to me in the #movabletype IRC channel]

Recent Comments