This invariably happens to me. I go on vacation, and then the server goes down. It doesn't go down during the year. It's had an uptime of over a year! However, it's down and stayed down. So, if you've been trying to email me, I apologize, it won't get through. The same goes if you're wondering where blog.jason.pollock.ca went to, or why I'm not on jabber anymore. I'm trying to get it going again, but email will probably be down until I get back home. The eBook Repositories will definitely not be updating, so the Baen Books will slowly rot.
Thursday, June 12, 2008
Saturday, June 07, 2008
Installer.app and chmod/chown
How is it that I would go about chmodding the directories created by CopyPath?
It seems that if the .zip contains the permissions already, they are maintained when used by CopyPath.
In other words, if you have:
foo/bar
in your .zip, and do a CopyPath("foo", "~/foo") in the XML document, the permissions are set up correctly. At least I haven't had any problems if my installer looks like that.
However, if you create implicitly create directories by using CopyPath on the individual files, they are created without permissions, and a chmod/chown is needed. For example, CopyPath("foo/bar", "nuts/baz/bar") will create "nuts/baz", with no permissions.
I have to do this with the Gutenberg SciFi and Baen Books libraries, since I don't host the .zips themselves.
To manage the chmod/chown problem, the packages ensure that the BSD subsystem is installed (or Cydia), and then runs them as part of the install steps.
Here is an example:
<key>preflight</key>
<array>
<array>
<string>IfNot</string>
<array>
<array>
<string>InstalledPackage</string>
<string>com.natetrue.iphone.iphone_binkit</string>
</array>
</array>
<array>
<array>
<string>AbortOperation</string>
<string>You must install the "BSD Subsystem" package from Installer first! It's in the System Category.</string>
</array>
</array>
</array>
</array>
Which checks for the BSD subsystem as part of the pre-install. If the BSD subsystem is not installed, the user gets a pop-up error message and the package will not install.
And then the install
<key>install</key>
<array>
<array>
<string>CopyPath</string>
<string>1013.txt</string>
<string>~/Media/EBooks/The_First_Men_in_the_Moon/1013.txt</string>
</array>
<array>
<string>If</string>
<array>
<array>
<string>FirmwareVersionIs</string>
<array>
<string>1.1.3</string>
<string>1.1.4</string>
</array>
</array>
</array>
<array>
<array>
<string>SetStatus</string>
<string>Changing Permissions</string>
</array>
<array>
<string>Exec</string>
<string>/bin/chmod -R 755 /var/mobile/Media/EBooks</string>
</array>
<array>
<string>Exec</string>
<string>/usr/bin/chown -R mobile /var/mobile/Media/EBooks/.</string>
</array>
<array>
<string>SetStatus</string>
<string>Running GutenMark</string>
</array>
<array>
<string>Exec</string>
<string>/usr/bin/GutenMark --profile=en --no-toc --config=/etc/GutenMark.cfg /var/mobile/Media/EBooks/The_First_Men_in_the_Moon/1013.txt /var/mobile/Media/EBooks/The_First_Men_in_the_Moon/1013-h.htm</string>
</array>
<array>
<string>SetStatus</string>
<string>Running GutenSplit</string>
</array>
<array>
<string>Exec</string>
<string>/usr/bin/GutenSplit --no-toc /var/mobile/Media/EBooks/The_First_Men_in_the_Moon/1013-h.htm /var/mobile/Media/EBooks/The_First_Men_in_the_Moon/Chapter_</string>
</array>
</array>
</array>
That's not the full install segment, but it should give you an idea. I have to separate 1.1.3/4 from earlier firmwares because they use different users and store files differently.
To help, I've created a little perl library that allows me to write packages without having to mess with the nasty XML. It's part of the iphoneebookrepo project over at google code. Specifically PlistMaker.pm.
In terms of the perl library, it ends up looking like this:
my $gutenberg_html_install =
p_if(IsFirmwareVersion("1.1.3", "1.1.4"),
SetStatus("Changing Permissions").
Exec("/bin/chmod -R 755 /var/mobile/Media/EBooks").
Exec("/usr/bin/chown -R mobile /var/mobile/Media/EBooks/.").
SetStatus("Running GutenSplit").
Exec("/usr/bin/GutenSplit -1 -2 -3 -4 --no-toc --no-skip /var/mobile/Media/EBooks/$BookDir/${BookNumber}-h.htm /var/mobile/Media/EBooks/$BookDir/Chapter_")
).
p_if(IsFirmwareVersion("1.0.0", "1.0.1", "1.0.2", "1.1.1", "1.1.2" ),
SetStatus("Changing Permissions").
Exec("/bin/chmod -R 755 /var/root/Media/EBooks") .
SetStatus("Running GutenSplit").
Exec("/usr/bin/GutenSplit -1 -2 -3 -4 --no-toc --no-skip /var/root/Media/EBooks/$BookDir/${BookNumber}-h.htm /var/root/Media/EBooks/$BookDir/Chapter_")
);
my %BookDescriptor = (
bundleIdentifier => "ca.pollock.gutenberg.$BookNumber",
name => $BookTitle,
version => "1.0",
location => $BookURL,
category => "Gutenberg SciFi (" .$BookLang . ")",
size => $BookSize,
hash => $BookMD5,
url => "http://jason-pollock.blogspot.com/",
maintainer => "Jason Pollock",
contact => 'jason@pollock.ca',
description => "by $BookAuthor",
install => $Book_install,
preflight => $Book_preflight,
postflight => "" ,
uninstall => $Book_uninstall,
update => ""
);
my $BookPLIST = CreatePackage(%BookDescriptor);
One "Gotcha" to be aware of... The Exec command is actually performing it's own parameter splitting prior to calling "Exec". It does not do any sort of "~" expansion, nor does it understand spaces. So, if you are doing a chmod on a directory with spaces in the name, it won't work, regardless of escapes or quotes.
Posted by
Jason Pollock
at
5:09 PM
0
comments
Labels: AppTapp Installer, Installer.app, iPhone
Sunday, May 11, 2008
The iPhone Gutenberg Science Fiction eBook Repository!
Yes, I managed to finish it. I've managed to convince Project Gutenberg books to install onto the iPhone.
To make use of the repository:
- Obtain an iPhone.
- Jailbreak the iPhone, I recommend ziphone for this task.
- Install Books, the iPhone ebook reader using the Installer application (1.4+ only!)
- Add the repository to Installer:
- Start Installer
- Click "Sources"
- Click "Edit"
- Click "Add"
- Enter "http://library.pollock.ca/gutenberg_scifi"
- Click "OK"
- Click "Done"
- Click "Refresh"
- Select "Install" at the bottom of the screen. You will see "Gutenberg SciFi" is now available as an application category!
- Before you can install a book, you will need to install GutenMark, it is under Utilities. I am using it to format the files on your phone to save me bandwidth.
There are currently 163 books in the library, in English and French. The list of books I used is from Gutenberg's SciFi CD collection. Since I can convert any Gutenberg book at this point, if there is a favourite you are looking for, please let me know.
The installation software has a preference for the HTML version of the book if it exists, however it will use the TXT version and pass it through GutenMark if it doesn't. Both versions will be split into chapters using the very handy GutenSplit.
Posted by
Jason Pollock
at
3:46 AM
10
comments
Friday, May 02, 2008
VoIP and 911
I see that another infant has died because a VoIP call wasn't properly routed to a 911 operator. Situations like this caused some very extreme results for US VoIP carriers - Vonage wasn't allowed to accept new customers for a couple of months until they sorted it out!
Every time I see one of these stories, I try to come up with a solution. Here's what I would do for this problem.
There are a couple of problems in the current solution that need to be solved. First, the call was routed based on the customer's billing data. That isn't accurate in the VoIP world. It's not even accurate in the fixed line world! Many people have phones that are billed to PO boxes or businesses that are not the physical location of the line. Second, E911 has the ability to locate an individual caller. Without that, if the call is disconnected, or the caller cannot speak, the 911 operator has no way of determining where the person needing help is.
First, the easy one. Routing based on billing data. This is pretty easy, DON'T DO IT!
We need to find some reasonably accurate geolocation data in a VoIP call. Thankfully, it's right there. The source IP address. Home VoIP will be at the end of either a cable or DSL modem. Either is a physical port. With a static IP address, it's well defined where they are. Even with a dynamic address, the address range is still geographically limited. Definitely accurate enough to select a 911 call center.
We can make use of commercial IP address geolocation databases to route to the nearest 911 operator. There are existing commercial databases that provide just this information. However, the data may be inaccurate. So, you add the data to the call. You now have a call with location data of the call and the billing data. If they disagree, you route based on the IP address and inform the call center to verify the region information.
Perhaps it's too simple a solution. VoIP telephony people (and most Internet people) view the Internet as a cloud, they don't trust IP addresses to identify locations (Telephony people have the opposite problem, they put too much trust in the phone number.)
However, society has started using IP addresses as not only identification of location, but of a specific user too. For an example, have a look at the RIAA lawsuits in the US. The IP address is sufficient to sue an individual for copyright infringement. It is used to identify not only the location the connection is made from, but to make a reasonable assertion to the identity of the individual!
So, current commercial IP address geolocation products have the information we need to properly route 911 calls to the local call center.
How do we get E911 levels of location accuracy? To do that, we need the help of the ISPs.
Remember, everyone is connecting through DSL or cable, or some other fixed-line connection. We will deal with mobile later. That means that the ISP has a mapping between the IP address and the physical port (at least for DSL, cable too probably). However, gaining access to this data will require government regulation and probably some money changing hands (carriers bill for 911 services).
If this database is also made available to the 911 operator, then we have a complete system, a database that maps an IP address to a call center, and then on from the IP address to the physical location. There is probably even a standard that we can use, since E911 services for mobile phones have the same problems.
So, what about mobile? Well, in the mobile world, we still have the IP address to location mapping, and the carrier still has the IP address to physical location mapping. However, it is a little more indirect. There is a mapping from IP address to phone number, and then the carrier can use their existing E911 services to locate the actual device.
Is any of this even expensive code? No, it isn't. That's the interesting bit. It's all information that is added on to the existing 911 call. Even without a correct geolocation of the IP address, the call center operator can still correct the problem by asking "Where are you?". This system will be there to provide additional information to the 911 operator, not replace them. Since the 911 operator themselves are a key component of this solution, additional training will undoubtedly be needed, including a change in some of the scripts they read from. Adding the city to the address for confirmation would solve many problems.
Where does this break down?
- VPN - If the phone is in a branch office, that routes IP traffic through a VPN to a different POP, it won't work. However, they've already got this exact same problem with corporate PBXs anyways, this isn't new.
- Calls from outside of the jurisdiction. If someone takes the device overseas to use it for cheap (free) long distance.
- Carriers making frequent changes to their routing rules. If a subnet moves from one region to another, 911 calls may have the wrong location until the database is updated.
Posted by
Jason Pollock
at
6:30 PM
0
comments
Tuesday, April 29, 2008
Baen Free Library iPhone eBook Repository Updated!
Since STE has released v 1.4 of the iPhone EBook reader, I have finally had to update the repository to support 1.4. The major change? It now places books in ~/Media/EBooks instead of /var/root/Media/EBooks. This is because Books.app only looks in ~/ now!
I took the opportunity and added some additional features:
- Cover Art! The books now display their cover art in the main title list.
- Chapter Sorting! The Books.app team removed a hack they had specifically put in for Baen, it was causing performance problems. I have renamed the html files to avoid the problem.
Well, I thought it was more features than that when I started.
If you already have the book installed, it should upgrade through Installer.app. I have tested a couple of books, so I'm reasonably confident it will work.
Also, since webscriptions has a habit of updating the .zip files every week or so, I now scan their site every hour to ensure that the source plist is up to date.
Again, if you run into any problems, file a bug report over at the google code project
Posted by
Jason Pollock
at
3:14 AM
0
comments
Labels: Baen Free Library, eBook, iPhone, repository
Tuesday, April 08, 2008
Truth in Advertising
If you say "Usually ships in 48 hours", it means that I should expect to see it ship in two business days. It also means that if I leave five business days, I should have the item in my little hands by the time I need it.
I'll understand if you are going to miss that deadline. Let me know, and give me the option of canceling my order. Leaving me guessing about the status of my order is frustrating and ultimately (as we'll see in a second) bad for business.
I won't be shopping at Gameplanet Store NZ again. I have placed two orders with them, the first one took an extraordinary amount of time to arrive, missing the party that I wanted it for.
I ordered a second game (mostly due to a $10 discount from the first order), and again it didn't ship inside of the 48 hour window. So, you have to ask, "What does 'Usually' mean to them?" To me, it means at least 95% of the time. How ever, two failures in two orders means it sure isn't 95% to them.
GPStore - Avoid, they're the "flying pig" of NZ software retailers.
Posted by
Jason Pollock
at
4:11 PM
3
comments
Friday, March 28, 2008
Announcing the iPhone eBook Repository
Installing eBooks onto the iPhone for reading was nearly impossible. You needed to download third party tools, use scp, rename files, the works. To help, I decided to package existing eBooks for viewing on the iPhone.
Since this is an AppTapp repository, the books can be installed onto the iPhone from any location that the device has a valid network connection, GPRS, EDGE or WiFi.
The current repository provides installation instructions for 117 SciFi novels from the Baen Free Library, with plans to add additional sources. I am currently working on Project Gutenberg.
To make use of the repository:
- Obtain an iPhone.
- Jailbreak the iPhone, I recommend ziphone for this task.
- Install Books, the iPhone ebook reader using the Installer application (http://code.google.com/p/iphoneebooks/ (1.37 only!))
- Add the repository to Installer:
- Start Installer
- Click "Sources"
- Click "Edit"
- Click "Add"
- Enter "http://library.pollock.ca/baen_books"
- Click "OK"
- Click "Done"
- Click "Refresh"
- Select "Install" at the bottom of the screen. You will see "Baen Free Library" is now available as an application category!
Just to clarify a couple of things. I am not providing copies of the .zip archives, they are provided to the iPhone by Webscription and Baen. The content of the files themselves are unchanged, although I have had to rename the html files to better fit in with the reader (I changed the SKU in the filename to Chapter).
To make it easy to spread these repositories around, I have uploaded the scripts I used to generate the repository to google code (iphoneebookrepo). If you would like to help, either with code, by reporting faults (thanks Ross!), or just general comments, I would appreciate it!
Take that Kindle!
Posted by
Jason Pollock
at
6:28 PM
8
comments
Labels: AppTapp Installer, eBook, iPhone, repository
Wednesday, March 26, 2008
AppTapp Exec bug
I released my project to a couple of friendly users. After giving it a try, one of the testers came back and told me the installer was leaving crufty directories lying around in the root directory.
I eventually tracked it down to this:
<array>
<string>Exec</string>
<string>/bin/mkdir -p "/var/root/Media/EBooks/Beyond World's End"</string>
</array>
Now, if this was in a shell, or passed to the OS using "system" or a similar call, it would work. However, it seems that they are using direct calls to exec. I can't really tell, because AppTapp is oddly closed source.
The directories it was creating were:
- "/var/root/Media/EBooks/Beyond
- /World's
- /End"
Fun!
Next up, I tried escaping the spaces, again with no luck. It looks like the code is splitting the parameters out through the use of spaces and ignores any attempt at grouping the packager might make.
Luckily CopyPath does the right thing, properly handling the spaces. It even creates parent directories, which is why I was using mkdir in the first place.
Now to figure out how to host it on Amazon S3. I really don't want a 2.5meg file being slurped across my cable modem every day!
Posted by
Jason Pollock
at
11:41 PM
2
comments
Labels: AppTapp Installer, Bug, Installer.app, iPhone
Tuesday, March 25, 2008
Debugging an iPhone repository
The AppTapp Installer doesn't provide any feedback during a failed install or source update. This makes it very difficult to create packages. At first, it really feels like you are stumbling around in the dark.
Here is what I learned from my project.
Installer.app ignores bad XML documents. If you have one good version of your repository, and then make a change that results in a "bad" one, you will still see the good copy that has been cached on the phone. This confused me for a long time.
Always test the document for correctness first. Firefox is a quick, easy test tool. Point it at the URL, and if it displays the XML in tree format, you at least know that your XML is balanced, and that your web server is configured correctly.
Next, run Installer.app manually on the iPhone. This should let you know what is going wrong with the package. (original source)
- make sure you are not running Installer.app
- ssh into your iPhone (root password is "alpine")
- for 1.1.3 firmware and higher: su - mobile
- maximize your ssh window
- cd /Applications/Installer.app
- ./Installer
- you will see Installer.app pop up on the iPhone's screen
- reproduce the error
- observe the debugging output from Installer.app in the ssh window
Finally, never, ever change the root password on your iPhone. You may think that because you are running an SSH server that is open to the world that it would be a good idea to change it. After all, there is a "passwd" command sitting right there in the terminal window. RESIST!
There is a problem with the 1.1.3 and later firmwares, and the version of passwd shipped with the BSD subsystem results in Springboard (the desktop shell) crashing continuously. I made this mistake and had to completely wipe the phone and restore it.
For security, install the services application, and disable the SSH server between uses. This will also help with the battery life of the phone!
Posted by
Jason Pollock
at
2:02 AM
0
comments
Labels: AppTapp Installer, debugging, howto, Installer.app, iPhone, package, password
Creating an iPhone AppTapp Repository.
I had a project where I needed to create a repository for AppTapp (Installer.app), the application used for over the air software installation on jailbroken iphones.
It's near impossible to find instructions on how to do this. If you google for them, all you get are "how to jailbreak your phone" and "how do I install applications" questions. Nothing about how to actually create a repository!
Thankfully, I eventually found the a wiki on ipodtouchfans with a detailed description.
The repository file is an XML document using Apple's plist format. Since it's XML it is both easy to pick up and nasty to use at the same time. The header portion of the plist file is self-explanatory, check out the wiki link. Here's the header from my test repository.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>info</key>
<dict>
<key>name</key>
<string>Testing</string>
<key>maintainer</key>
<string>Jason Pollock</string>
<key>contact</key>
<string>jason@pollock.ca</string>
<key>url</key>
<string>http://www.pollock.ca/repos/baen</string>
<key>category</key>
<string>TestRepositories</string>
</dict>
<key>packages</key>
<array>
</array>
</dict>
</plist>
The individual package instructions go in the final array. However, this is a fully specified (if empty) repository. If you place it on a publicly accessible URL, people will be able to add it to Installer.app and track updates!
Next are the individual packages and installation scripts. The package themselves are separated into scripts and .zip archives. There is no provision to deliver software in any other format.
The install/uninstall scripts are part of the repository XML, not the .zip archive. This means that you can host the .zip files on a cheap, low cost volume server, while the xml document (since it is generally smaller) can be hosted closer to you. Web servers are more able to cache the repository document. Hopefully, with a single http request, the application is able to tell from the header response if the repository has changed, keeping transfers to a minimum. To keep from having someone change the .zip file on you, both a size and an md5 hash are provided in the plist file. Finally, the separation between script and installed files allows other people to provide fixed installers for your application!
The install/uninstall scripts are also XML, complete with if/then/else syntax. This is near impossible to either understand or get right due to all of the tag nesting, and chaining of siblings without explicit keyword enclosures. For example, let's look at an extremely simple "if" block to check the firmware version.
First, the logic in C, just to let you see what it should be doing:
if (! FirmwareVersionIs("1.1.2")) {
AbortOperation("Firmware 1.1.2 is required to update to 1.1.3.");
}
Now for the insanely verbose XML code.
<array>
<string>IfNot</string>
<array>
<array>
<string>FirmwareVersionIs</string>
<array>
<string>1.1.2</string>
</array>
</array>
</array>
<array>
<array>
<string>AbortOperation</string>
<string>Firmware 1.1.2 is required to update to 1.1.3.</string>
</array>
</array>
</array>
Completely impenetrable.
Installer.app works best when the .zip is already in the destination layout. Then the installation process is relatively simple. However, if not, each file must be individually copied into its target location, using the <CopyPath> command.
<array>
<string>CopyPath</string>
<string>iZoo.app/</string>
<string>/Applications/iZoo.app</string>
</array>
There are several gotchas.
First, if you create directories, Installer.app creates them with no permissions what so ever, you will need to perform a chmod!
Second, the location of the Media tree was moved between 1.1.2 and 1.1.3. In current releases of the iPhone firmware, applications run as the user mobile. This means that the Media tree (where the music/etc is stored), is now in /var/mobile/Media instead of /var/root/Media. Since applications are installed on both 1.1.2 and later versions of the firmware, they need to work on both. To help with this, Installer.app has added support for "~", to refer to the home directory for the user. Again, however, this depends on a specific version of Installer.app being present. Personally, I chose to ignore all of this, since the application I was using didn't know about /var/mobile/Media anyways. Still, it is something that developers will need to figure out.
Third the syntax in the scripts is nasty. If you find yourself writing a fair bit of it, write a tool to do it for you. I'm sure it is possible to come up with a more human readable syntax that will generate the XML for you.
Finally, debugging your packages is painful and slow. However, that's for the next post.
Other than that, there's nothing too difficult about the whole thing. If the zip file you are trying to install is already in the target layout, it's dead simple.
Enjoy!
Posted by
Jason Pollock
at
1:22 AM
1 comments
Labels: AppTapp Installer, howto, Installer.app, iPhone, package, repository
Thursday, March 20, 2008
No, you are not a valued "Contact"
A curious thing happened to me today. I got a connection request on LinkedIn. Obviously it isn't the request itself that was interesting. It was the combination of the request and who it came from.
I haven't had a single positive experience with this individual. I have found them to be extremely rude and unprofessional.
So, why would they ask to connect to my network? Obviously they've just joined LinkedIn and have selected everyone that listed the same employer.
Tip: When you join a social networking site, don't do that.
However, it leaves me with a dilemma. This individual is pretty senior in the company.
Do I click "Accept" and hope to gain more value from their connections than I lose by having their stench rub off on me?
Do I click "Reject" and let them know that what I really think of them?
I think I'll go with the third option, and click "Archive", stashing them with all the other people I don't like. Someone else in the company that I am connected to will click "Accept", so I'll still have access to their connections, and their stink will be at least one level removed.
Ah, social networking.
Posted by
Jason Pollock
at
11:02 PM
2
comments
Wednesday, March 19, 2008
iCal, how can you do this to me?
After talking to Bruce, it seems that he has some of the same concerns for timezones that I do.
In a post, he pointed to something called VTIMEZONE. So, I went looking to see if perhaps there was another angle to this whole timezone storage mess.
VTIMEZONE is a data element attached to local times in iCal. It seems that when a recurring event is passed in iCal, it MUST have a VTIMEZONE component. So far so good. However, that VTIMEZONE record MUST specify information for DST! Bad iCal!
Of course, since this information is instantly incorrect, we end up with the problem we have had before. Even worse, because the information is fully specified in the message, developers are probably correct in assuming that they can't ignore the data and substitute their own information!
Personally, I feel this is a bug in iCal. I can see why it exists, to hand-wave around the timezone differences between Windows and OSX/Unix. At least they make a reference to the Olson (on which zoneinfo is based) database.
Developers, when implementing an iCal parser, use the VTIMEZONE value you receive as a way to determine the timezone, not as an actual descriptor. Based on the information in the VTIMEZONE component, find the timezone in your own TZ database and use that name when referring to the event. Never, ever, cache the definition.
Posted by
Jason Pollock
at
1:34 PM
0
comments
Labels: Bug, daylight savings, iCal, timezone
Tuesday, March 18, 2008
Timezones and the FUTURE!
After reading Novell's report of the DST problem in GroupWise, I understand that a lot of these are software faults, and not problems with the OS or the timezone settings themselves.
When dealing with multiple timezones, what will a developer do? They’ll convert it to UTC for storage and comparison and then convert it back for display. This solution appears to completely remove the timezone from the problem and gives the developer a nice, sortable value to store.
Everything works fine until someone changes the start or end of DST. Immediately, all of the timestamps that were previously created for that period between the old and new start (and end) dates will be out by an hour.
If you’ve got a monthly/weekly recurring meeting it will be out by an hour into perpetuity for that 1 week every year.
The real fix is to store dates/times in the originator’s timezone and then convert them on the fly. It makes sorting a pain in the ass (time is no longer a single int!), but we’ve got CPU to burn so why not?
One final gotcha with that. You CANNOT store the originator's timezone as an offset! It needs to be a name used to retrieve the TZ information. If it is stored as an offset (I'm looking at you Oracle), you have the exact same problem. Using a name means that it becomes difficult to create an index across timestamps with mixed timezones, but the values will be correct!
The lesson to take away? You cannot convert a timestamp to UTC for storage if that timestamp is in the future.
Posted by
Jason Pollock
at
2:10 PM
2
comments
Labels: Bug, daylight savings, timezone
Monday, February 11, 2008
The only thing worse than being ignored...
Is having your ideas used and not being given credit.
Credit is important in the knowledge economy. Personal credibility is how you get and retain employment. Without credibility, don't expect to move up the chain.
One of the sales people I work with came up with a cool idea, it would instantly double or triple the number of customers for the company. So, he did what he thought was the smart thing. When the CEO took them out for dinner, he told him about it. He sent an email around the marketing team. He had design discussions looking for angles on his own time with interested members of the engineering team.
The marketing team went quiet. There was no indication that the company would proceed with the idea. Definitely nothing along the lines of a "thank you". Of course, based on my experience, that's to be expected.
Imagine his surprise when I went up to him this morning and said, "Congratulations on that thing! I see from the press release that you got some traction! Great!"
The hurt was visible. At first he was angry, "That jerk stole my idea", then he was incredibly hurt.
I can tell you for sure, he's another person who has had his creativity killed. Do you really think that after this experience he's going to bring his A-game to work? I've never seen the fire go out of someone before. It's a sad thing to see.
He's an insanely motivated and energetic guy. If I worked somewhere else, I would be inviting him out to lunch right now.
Posted by
Jason Pollock
at
1:49 PM
0
comments
Tuesday, December 11, 2007
Camera Phones are Everywhere
If you doubt the ubiquity of cameraphones, check out this picture:
You've got a little girl at a museum in Belgrade, taking a picture of a cool rock with a cameraphone. Five years ago, you would never see a phone with a camera, let alone a child with one. It will be interesting to see what happens now that we can assume that everyone has both a phone and a camera.
Cool times ahead!
Posted by
Jason Pollock
at
3:16 PM
2
comments
Thursday, November 29, 2007
ActiveRecord Columns
It can be hard to keep up on side projects, there are just so many other things around the house demanding attention. This week, I've been spending my time demolishing a brick BBQ/planter in the back yard. I've removed 3 cubic meters of dirt and brick! Last night I finished that, so I started to think about the side project I'm working on. As I did, I thought back to the WTF moment I wrote about a while ago, and I was afraid that I was wrong. Totally wrong. Idiotically wrong in a way that would demonstrate that I am a complete total and utter Ruby on Rails noob.
It's interesting about blog posts. I've added Feedburner so I have a bit better an idea of how many people are reading this. Before, I thought it was just a couple of friends and then only when I bugged them, "Hey, did you see my new post?". Now, it seems I have a readership (albeit minimal).
That means that any mistakes I make here are really, really public and enduring. Of course, for me that's part of the point of the blog. I want to be able to go back and see how my ideas change over the years.
Anyways, back to Rails. I was afraid that this code was wrong:
def update_my_status(user, status)
if (a_party == user)
self.a_party_status = status
else
self.b_party_status = status
end
end
I was sitting there thinking, "Wait a second, Ruby says that data members have an '@' in front of them!", quickly followed by, "Nuts, so, do I edit or delete the previous post?"
Just to be sure, I went and fired up the rails console. Very, handy, much recommended. I modified the code to look like this:
class Call < ActiveRecord::Base
def my_status(user)
if (@a_party == user)
@a_party_status
else
@b_party_status
end
end
...
I then called it in the console:
>> call = Call.find(:first)
=> #
>> call.my_status(2)
=> nil
Whew, off the hook. It seems that Ruby has "method missing" functionality, but not "member missing" functionality. So, when I put an '@' in front of it, ActiveRecord doesn't know to look up the value in @attributes. Interesting, and a bit more learned about the internals of ActiveRecord and Rails.
Posted by
Jason Pollock
at
11:50 AM
2
comments
Labels: ActiveRecord, Ruby on Rails
Wednesday, November 14, 2007
Lying, redux.
Happened to me today:
"The NFS mounts are all broken, what's changed on the server?"
"Nothing"
"Well, obviously something's changed, or else it would work. What's changed?"
"Nothing"
...
Several more times back and forth...
"Listen, it's pretty [bleeping] obvious that you have [bleeping] changed something. What the [bleep] have you changed so that I can fix my [bleeping] systems and get some [bleeping] work done!"
"Take a chill pill, and relax dude!"
Bull? Meet Mr. Red Flag.
The actual problem? They changed the directory layout of the NFS mount, so everything moved around. Amazingly, he was surprised when everything stopped working.
Lesson? I need to realise that although the guy is lying his ass off, I need to walk away instead of rubbing his nose in it. I'm not going to get a resolution. I need to follow my own advice, and give people back their monkeys.
So, in the future, I'll just send a polite email (CC'ing my supervisor, and their supervisor), explaining why no one in the entire support organisation is able to get any work done. Hopefully they'll get it resolved by the end of the day.
Oh wait, just yesterday I gave someone advice because they had a technical manager doing exactly that! What did I say? Oh yeah, "He's looking for a reason to slip his project and he's looking to blame you. He should know how to manage his own development systems."
So, either I look like a dick because I put the beat down on some poor overworked IT guy who seems to have been here late screwing it up in the first place (and then bald-faced lying about changing anything), or I look like a dick because I'm looking to blame someone for my schedule slippages.
Hmm. I think I'll walk away and talk to someone else in the team next time. That guy has managed to flip my idiot bit.
Posted by
Jason Pollock
at
4:53 PM
2
comments
Labels: communication, lying
Monday, November 12, 2007
Google's Android
I was looking at the docs for the SDK today. I'm interested to see if I need to get an OpenMoko to play with this sucker. However, I haven't been able to find the OS itself, just references to the eclipse plugin.
Even worse is this quote from the FAQ:
Android does not currently support development of third party applications in native code (C/C++).
Not as open as we had all hoped. I'll keep looking, I hope it gets better.
Sunday, November 11, 2007
Recovering a corrupted Akregator feed list
Akregator has an annoying habit of losing your configured feeds when it shuts down abnormally (as in whenever it's "killed"). It's supposed to have a backup of the file, but it manages to truncate that file too.
However, I've found a second backup of the file, ~/.kde/share/apps/akregator/Archive/feedlistbackup.mk4
It contains some binary data at the top, and then appears to have a several different versions of the opml file.
To recover:
cd ~/.kde/share/apps/akregator/Archive/
cp feedlistbackup.mk4 ../data/protect_my_backup
[shut down akregator]
cp feedlistbackup.mk4 feeds.opml
vi feeds.opml
[remove the binary data at the top of the file, leaving the XML declaration tag and the <opml>...</opml> section. Remove everything from the first </opml> to the end of the file.]
[restart akregator]
Just remember, copy the file as soon as you see the problem, if you shut akgregator down, it will overwrite the backup file when it manages to exit properly.
If that "feedlistbackup.mk4" doesn't look right, you can always try to recover the opml file from the list of sites in the archive. However, it won't be organised into folders, and it will probably have all the feeds you have ever subscribed to.
Posted by
Jason Pollock
at
12:27 PM
5
comments
Labels: akregator, bug corruption, feeds.opml
Wednesday, October 31, 2007
No I don't want to unlock your iPhone for you
Just because I've got one, and I love it, doesn't mean I'll help you with yours. It was hard enough for me to unlock mine that my recommendation on the device is this:
"If you aren't a developer familiar with SSH, firmware, networks, bootloaders, and Unix go buy something else. This device is not for you."
That includes buying one that is already unlocked. You will eventually screw up and be back to using ssh and command line shells.
I've got my own projects, and I really don't want to spend my life unlocking other people's phones when I could be having fun.
So, no, I don't want to help you unlock your phone.
The only person I will help is my wife, and that's because, well, I love her. If you aren't her, I don't love you enough, and you can't afford my hourly rate.
Posted by
Jason Pollock
at
6:03 PM
2
comments