-- if I can't get the Internet, and Outlook wants to send email, then it behaves badly. -- since I'm usually on battery in those conditions, this is not good and must be stopped. -- of course this is a rare condition, so this script needs to be light on CPU too. -- is Outlook even running? tell application "System Events" set outlook_running to (name of processes) contains "Microsoft Outlook" end tell if (outlook_running) then -- do I have a network address? set ipaddr to IPv4 address of (get system info) if (ipaddr is not "127.0.0.1") then -- Am I really on the Internet (evil gateways don't count) set is_splunk to (do shell script "curl -s -I www.splunk.com | grep -c splunk") if (is_splunk > 0) then -- it's safe to work online now tell application "Microsoft Outlook" set working offline to "false" return ((current date) & "Set Outlook to work online.") end tell end if else -- if Outlook is running but I don't have an address or I'm not really on the Internet, it might be a good idea to work offline. -- Commented out the bits that think about that decision. --if (is_splunk < 1) then -- tell application "Microsoft Outlook" -- set outbox_count to count every message of mail folder "Outbox" -- end tell -- if (outbox_count is greater than 0) then -- tell application "System Events" -- try -- set The_app to "Microsoft Outlook" -- set pid to the unix id of process The_app as Unicode text -- set cpu to (do shell script "ps -o %cpu -p " & quoted form of pid & "| tail -n 1") -- end try -- end tell -- -- if (cpu is greater than 50) then tell application "Microsoft Outlook" set working offline to true return ((current date) & "Set Outlook to work offline.") end tell -- end if -- end if --end if end if end if
Monday, July 23, 2012
Here's an AppleScript to deal with Outlook getting itchy if there's email in the outbox and no Internet connection to send it over. Sucks to have your battery die on a plane over something stupid like that.
Sunday, July 8, 2012
Software vendor people have all sorts of different backgrounds... while lawyers and architects might have pretty similar educations, software people could have been educated in liberal arts or pre-med or hard knocks instead of STEM or EECS. Furthermore, they might have more experience in selling or more experience in servicing, or no customer-facing experience at all. Some have worked for lots of vendors, some have worked only at customers, while others stumbled into this opportunity straight out of high school or college and know little else. This leads to a pretty wide variance in risk tolerance, which can have funny effects on planning.
"Product XYZ has issues!" Of course it does. Every product has issues. The question is, what will the team do about them? Is it worth holding up the release to fix it? Possibly, but after some number of flare ups don't be surprised if some of your colleagues want to pull back from doing XYZ at all. This must be stopped, and firmly. Remember all that research on the competitive market and customer demand? Remember the reasons that your company is well-suited to take a piece of this pie? Letting some risk-adverse colleagues block your success is a sad way to fail.
The product may have issues, but if you don't sell it, they will never be fixed. Sales are the oxygen of products, and you might as well not bother if the story isn't good enough to produce a flow of oxygen.