I finally completed the last of the core courses for the HCI program. Now I only need to take two more electives and do the capstone. This last class was definitely one of the better courses I have taken. While it was similar to the HCI 460 course it is different in that it focused more on the the initial user observations whereas 460 was about usability testing methods and reporting. The class started out with us doing our own user observation. This involved finding a task to study a user performing. Then finding a user and arranging a time to observe them.
Working on a recent layout, I was finally confronted with the need to have an IE CSS hack. I hate hacks, because they often break with browser updates and aren’t easily remembered. So I avoid them as much as possible. However, I finally succumbed to having to use a hack… except the method I use is not a hack so much as relying on IE functionality. My designs typically can be made to work in Opera, Mozilla/Firefox and Safari browsers very easily, and then occasionally take some head pounding to get to work for IE (first windows then mac). While some might suggest designing for IE first, that is not desirable as I use a mac to develop on, although I do use a PC at work. Also, when resolving a design for IE first, it is tempting to not check the others, as IE is still the browser of the masses. Working with Safari, Mozilla first gets the less numerous browsers out of the way. The additional nightmare of IE is that you have to deal with the subversions, 5.0 does not work the same as 5.5, which is not the same as 6.x (don’t mention 4.x browsers).
Intel Macs have been released and they are even better than I could imagine. They came out with a new iMac with dual core Intel and new powerbooks. All the rumor sites were saying that it was going to be the mini or the iBook and all I kept thinking was how could they possibly pass up the PowerBook. It is (or was) their top selling system, which was in fast decline becuase of the aging G4. I just couldn’t see any way for them to do the iBook especially without doing the pro level laptop as well. On the otherhand, while they didn’t do the mini just yet (I think they will have something in April), they did do the iMac, which leaves the PowerMac desktops in a precarious position. They did release a twin-dual core (quad) G5 desktop late last year, so it is still a step up from the single dual core Intel iMac, but how many developers are going to spend time optimizing for the G5 versus the new Intel systems which are the future. Another drawback for the Intel iMacs is the all-in-one form have a limited appeal for thoses who only want a system, so I guess it makes sense. I just wish I had a couple grand to buy one of the new MacBooks… yes, they had to change the name since it no longer has a powerpc chip and everybody is ripping on the name.
At first, I thought the name wasn’t that great either, then I kind of warmed up to it, since they are really nice systems. Then writing this post I realized; What the heck are they going to call the PowerMac once it is switched to Intel? Please not the MacMac Pro! Ah well, despite the name, I may look around for a freelance job or two to do in the evening or weekends to try and get enough money to get one of the new laptops. Don’t know how I will fit that in with school too… I guess I can wait til later this year or next year. Or if anyone wants to donate some money…
[update 2011-03-27: Kind of funny reading this now and thinking about Oracle being the one to end up buying Sun last year. Sun’s days were truly numbered when linux started to really gain traction in the server space]
This is to go along with every other “MS should buy X” story out there… Ok this sounds crazy, but really this is the best strategy that MS could have… buy Sun. It would probably end-up being a hostile takeover, but it would make sense for MS whatever the cost. MS keeps talking about their current strategy to run a command line interface (cli) on top of windows. In fact they already have it and are working to make it robust enough to woo unix types over to the windows platform. But this is a joke of the largest proportions as the problem with running windows with the cli on top, is that it does not solve the code problems with both security and performance underneath.
Recently, I’ve had conversations with a few of my developer friends who are all a twitter about AJAX. Saying how great it is and all the cool things Google is doing with it. Honestly, after taking a real close look at it, I find it to be hardly more than another buzzword. It simply does not offer anything of real value for web development. Yes, it can make interfacing with certain web applications smoother, and it solves some problems inherent in web applications. However, it introduces a whole set of other problems, that in my opinion, make it widely unsuitable for most work.
I worked a little more with automator (when I should have been studying regression analysis)… and have come up with a cool new automator. This incorporates an undocumented aspect of automator, so it took some trial and error to figure out. Basically, I wanted something that would allow me to turn a request to view a man page into a pdf file for easy printing and viewing in the gui side of Mac OS X. Only a unix geek could love the man page as it is… for unix newbies though, it can be quite frustrating. Personally, I am use to man pages, but I still like to print some out now and then and converting them to pdf allows me to access them without opening terminal (not that you wouldn’t probably have terminal open anyway).
So I wanted to find a way to make a man page into a pdf. Of course you can do this from the terminal, but where’s the fun in that (plus you have to remember the commands each time you want to do this). There is a free GUI utility called ManOpener that allows you to view man pages easily as well, and is much more featured than this automator tool. But if all you want (as I did) was a man page made into a pdf, then this is what you need to do;
- Open Automator, from the Library column select TextEdit. From the actions drag “Ask for Text” over to the workflow area.
- In the question field type “Enter man page name?” or something to indicate what you need to enter
- You can leave the default field empty or enter something that will serve as a reminder of what to enter
- Check the require answer box
- Next, from the Library column select Automator, then from the actions drag over the “Run Shell Script” to the workflow after the previous item. Type or copy & paste the following as one line, modifying the paths so that they point to your preferred locations (include the quote marks this time);
man -t $@ > /hardrive/Users/Shared/manpages/$@.ps | echo -n “harddrive:Users:Shared:manpages:”$@”.ps”
Set the “Pass Input” to “as arguments”
Note: The $@ takes the value entered in the “Ask for Text” and runs it as a shell command. The first part which calls the man page then passes it to a postscript file named with the name of the man you are looking for, then it echoes out the path to the next function. The echoed path has to be in the style of the Mac OS drive path reference which uses “:” instead of slashes “/”.
- Last select Finder from the Library column and drag “Open Finder Items” to the workflow in the last place. Set the “open with” field to the Preview application. The path passed from the previous action will be opened in Preview converting it into a pdf.
You are ready to test, click the run arrow and try it out. If everything works, the requested man page will be open in Preview at this point. You can either save it or discard it after use. You can get fancy and do things like check for existing ps files or remove the ps file after it is converted. But this gives you the idea of what fun you can have with automator and how it can make working with unix fun. Be sure to save your workflow and make it readily accessible on your dock or wherever you like to put things to be accessed often.
When I first heard about Automator it sounded cool, but I wasn’t sure what I could use it for personally. After I had upgraded to Tiger, I got around to looking at automator and to be honest, I didn’t see anything that would really help me. I looked at the sample workflows and there was nothing that applied to my everyday or even once in a while tasks.
However, the other day I was in need of combining a couple of pdf files. I knew there was a way to do this in Mac OS X, so I set about searching the internet. I thought I had seen a terminal command process to combine pdfs, but I found instead some instructions on how to do it with automator. So I am posting here in case the reference gets lost from somewhere else…
- First open Automator, select Finder in the Library and drag “Ask for Finder items”, check the multiple option.
- Then select PDF in the Library and drag “Combine PDF Pages” set to Appending pages
- Then go back to the Finder listing in the Library and drag the “Rename Finder Items” set things the way you would like here
- Then drag a “Move Finder Items” and set it to where you would like the new file to end up
Save your workflow and then run it. Pretty cool. Other variations could substitute Get Folder Contents for step 1. Then you can just drop files you want to combine into that folder and run the command. You can include the Sort Finder Items to change the order the pdf files are combined (or you could just rename them in the finder). Now that I have a taste and feel for what Automator can really do, I have something else to play with/do in my non-existant free time. Here is the forum where I found this http://www.macosx.com/forums/showthread.php?t=239682.