Welcome to RocketMonkeys.com!

This is my personal site, where I store my rants, pictures, and movie reviews. Have a look around, register and leave comments.

Show: all [rants] movies pictures

Page: Previous << 0 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 >> Next

Keeping Track of Hours Spent on Projects, the Easy Way

Posted by james on Oct. 22, 2009

Since I work best this way, I tend to work on a few projects during my typical day. I'll work on a project for a few hours until I get tired of it, then switch gears and work on something else. I got this advice from a previous teacher, and it works well for me. The problem is that you can get bogged down working on something and lose momentum. If you switch to something else, you tend to be able to focus better since it's something new. Then you come back to your original project, and those complicated things seem so much more easy, and you might even see something you were missing before.

However, this makes it really hard to keep track of hours spent. I've tried writing down my start & stop times, but it's just so hard to remember to do that when you switch tasks, especially since you're probably wrapped up in some problem at the time. I've also tried making a simple screenshot script that takes screenshots every X minutes, and then I can look back at a visual log of my day. However, that's really annoying to comb through.

I just completed a simple script that does just what I need, and it seems to be working well. Instead of taking screenshots, I have a script that scans a folder and records any modified files since the last time it ran. I have it running every 10 minutes, and it spits out a CSV log of modified files. I then have a web app that takes this CSV file and graphs it for any given day.

This gives me a very pretty and incredibly useful graph of my work on that project during the day.

I can easily see at a glance when I worked, and also when I took breaks. The best thing about this is that it works retroactively, so I don't have to remember to write anything down first, there's nothing to forget. At the end of the day I just look at my log and I can tell exactly how much I've worked.

Some details: the scanning script is in python, run at the lowest process priority. It creates a separate mod log for each give folder (to track different projects). The web app is written in django, and it loads the CSV log file, scans for each day, then graphs the results with the awesome and simple Google Graph API. That's it.

I think this might be nice to package into an installable program. I might do this if there's enough demand. At any rate, this satisfies my need and it's really nice to have this working. There have been enough times where I've had to try to figure out when I worked during the week, only to have to estimate after the fact. I tend to estimate on the low side so that I'm not taking advantage of anyone, but that means I'm losing hours. Now I'll make sure to get accurate counts, even if I'm filling out my timecard days later. Awesome.

GMail's labels are broken!!! (2 bugs found)

Posted by james on Oct. 18, 2009

I've had a disconcerting realization today, and it's really got me worried. For a while I've noticed that I can't seem to find certain emails in some of my saved gmail searches. For example, I have a label "work" and a search "in:inbox label:work". Theoretically that should show me all "work" emails that are still in my inbox. This is invaluable for letting me filter my inbox depending on what I'm doing.

However, I just discovered two bugs in the way gmail handles label searches. First, some emails are out of order. If I look at a conversation in my inbox with the "work" label, it shows up as "4:30pm". This is the date of the last email received in this conversation. However, if I click on the "work" label to see all conversations with the "work" label, it disappears. That's because now it's dated as "Jul 29", which is the date of the first email ever received for that conversation. This is an obvious bug, and makes labels very unpredictable.

But that's nothing compared to the second bug. While clicking on the "work" label (which results in the "label:work" gmail search) shows the message out of order, searching for "in:inbox label:work" causes this email to disappear completely. It doesn't show up in the gmail search results, even though it's clearly in the inbox and has the label "work"!!!

This by itself means that label searches are unreliable. It also begs the question; how many emails am I never seeing due to this gmail bug? If I constantly check my "label:work in:inbox" search to find new work emails, I'll never see certain messages. I'll only see them when I view the plain inbox, where it may be far down the list or on the second page. At best, this will cause a delay and confusion. At worst, this could result in import emails being ignored and left unnoticed.

What's strange about these bugs is that they happen for some conversations consistently, and not others at all. There must be a certain commonality between these conversations why they disappear in certain searches, while others show up fine. I haven't yet found the link.

The only workaround at the moment is simply not to use label searches, since they are unreliable. However, these two bugs remain and should be fixed. This bug has me rattled, since email is vitally important to my professional work and this could cause some confusion and trouble at work; lost time, bad impressions, miscommunication.

Or has it caused this already? I really can't say, but it has me scared.

TinyMCE mangles URLs by default

Posted by james on Sept. 22, 2009

I've been using TinyMCE as a WYSIWYG HTML editor for a while. I like it; it's light, relatively easy to use, and capable enough for most things. I really wish they had better image uploading support, but besides that, I've had little to complain about.

However, I ran into a problem that really frustrated me. I'd edit a mailing list email, add some links to a webpage, preview everything to make sure it works, then send it out. And then all the URLs in the email would be bad. They'd like to something like "../../some_link" instead of "http://www.server.com/some_link". This is not a big deal on a blog post where you can re-edit to your hearts content, but is a big problem when you're sending out emails. Obviously TinyMCE was mangling these URLs, but why?

Turns out that by default, TinyMCE is set to mangle all URLs, and it does this in a very unintelligent way. It converts a full URL into a relative one - relative to the script path. However, all of my sites put scripts in a separate /scripts folder (and so do many sites I've come across), so this all but guarantees that most URLs will be invalid by default.

To fix this:
relative_urls: false,
remove_script_host: false

This uses jQuery, but the TinyMCE options are what's important here. The "relative_urls" turns off the absolute to relative conversion. And the "remove_script_host" turns off the URL mangling for the first part of the full URL.

This fixes the immediate problem, but it also shows a flaw in TinyMCE. Any program's default settings to default to safe, understandable operation. In this case, the default is to mangle URLs in a way that almost guarantees they'll be wrong. While reading the manual may have helped in this case, probably not: the setting doesn't have "url" in it, like the other two url-related settings (convert_urls being the other one), and it's not obvious that "relative_urls" or "convert_urls" do nothing to fix this unless you also happen upon "remove_script_host" as well. I only happened to stumble on an example that showed all these options being used.

TinyMCE is not a bad script, and it is very helpful. But it is also confusing in this case, and it seems like some design decisions could improve things (change the defaults to be safe instead of "convenient", change the parameter names to be more consistent, add notes in the documentation for each option to show *exactly* what they do).

Page: Previous << 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 >> Next