Category: Main

Posted on

Does beta mean anything anymore?

I’m currently testing ReceiptWallet 2.0 beta and have been getting reports from people that say they’re using ReceiptWallet 2.0 (not saying beta) and are mad that they have problems. While I can understand being mad about having problems, but that’s why it is in beta so that people test it. I have several warnings indicating that the software is not finished and to backup data, but people seem to ignore those warnings. In my preferences, I have “Look for Beta Versions and Releases” as an option; I’m not sure people understand what Beta means, so I’ve changed it to “Look for Untested Versions and Releases”. Could that be clearer? When my website is redone, I’ll also make sure that any references to beta also indicate “untested”.

I think that developers have diluted the term beta by just throwing stuff out there and getting people to try it; for instance, look on VersionTracker for items that are beta versions. They are just mixed in with everything else and the unsuspecting consumer, says “oh, a new version, let me get it.” without realizing that beta means “untested”. I don’t throw my beta versions on VersionTracker because I want people to make a conscious effort to get the versions.

Posted on

Half baked PPP implementation

I love that Mac OS X is built on a UNIX core as I can use a command line to do stuff and write shell scripts. However, in some cases, Apple has wrapped a pretty interface on top of some UNIX stuff and made a mess as such as with the case with Mac OS X server; I wrote about this awhile back. This is also the case with PPP. System Preferences (and under Tiger, Internet Connect) hides the underlying PPP implementation. For most people, this works OK, but the biggest problem is that if you enter your username and password (for providers that require it), unplug the modem and plug it into a different USB port, that information is no longer associated with that modem. This is because PPP tracks the modem based on UNIX /dev port, i.e. /dev/usbmodem1d11. Each USB port is uniquely identified and if you plug in a hub, it changes the /dev port as well. So this can be quite problematic and each time you plug in the device into a different port, you’ll get a different entry in Network Preferences. What a mess. To make matters worse, the PPP implementation uses the keychain sometimes and then sometimes picks the wrong entry in the keychain if there are 2 entries with the same account name.

So why would I care about PPP these days when most people connect over a broadband connection and have their Macs connected via AirPort or Ethernet? One of my clients manufactures cellular modems, so I have to write code to deal with switching ports. Dealing with the PPP password is a huge headache. This would be so much simpler if the wireless carriers used Mobile IP which doesn’t require a username and password (Sprint uses it in the US). Why carriers require a username and password, I have no idea. When the modem connects to the network, they know who is connecting based on the ESN (Electronic Serial Number) of the modem, so why not authenticate off that? It’s not like normal people can change the ESN (it’s illegal and the tools are not readily available).

I’m sure that Apple will continue to ignore PPP as it works most of the time for most people. They should be tracking the USB modem based on serial number or vendor ID and product ID; something that won’t change.

(Yes, this is beat on Apple week.)

Posted on

Being self-employed and working from home

Note: this is a long narrative that I’ve probably written before, but it helps me to get stuff off my mind by writing.

Periodically people ask me about being self employed and working from home. I’ve been self-employed for almost 5 years (5 years next month) and have been working from home for 8.5 years. So, I have a bit of experience with both parts; while they are related for me, they are quite distinct in how they affect my life.

This is my second stint of working at home; the first time I worked at home was when the small company I worked for closed its offices and I worked at home, in Portland, OR, for a few months. I was miserable; I had only lived in Portland about 5 months, had just bought a house, and didn’t know anyone. I was pretty much just looking for a job and moping around until I landed my next job and actually went into an office everyone. Portland finally got to me and I decided to pack up and move back to San Diego (I only lasted 14 months in Portland; I couldn’t take the rain). After I made my decision, I gave my bosses the customary 2 weeks notice that I was leaving (I had nothing lined up, but I didn’t care). They were pleased with my work (I worked there for 6 months prior to this) and asked if I’d still work for them. I said, “why not?” and continued to work for them for another 3.5 years working out of my apartment and then my house. As I made the decision to work from home and enjoyed where I was living, working from home treated me well. However, I did have some issues. Most importantly, I worked too much. In an 8 hours day, I put in 8 hours of work which meant I typically put in 25% more than people in an office due to chit chat and water cooler talk. For me, this wasn’t a bad thing, but my boss told me I worked too fast.

I parted with that company on good terms as they had no work for me and I was bored out of my mind as I didn’t have work for the last few months of working for them; I literally played video games all day and got paid for it. So, that stint of working from home worked out well; I kept normal hours and had no reason to overwork (I was salaried). I have the kind of personality that can handle being isolated at work; I like to get my work done and don’t mess around. Other people would go stir crazy as they need the interaction of an office; I’m most efficient when I have few distractions which works well for working at home.

Continuing on, at that point, I had already being contracting part time for another company, so starting to be completely self-employed was not a huge leap, but a little scary at first. Where would clients come from? How much time would I have to spend finding them? Would I earn enough money? Well, clients just seemed to come to me; word of mouth is quite powerful. I haven’t had to look for clients and have had enough work (at times more than I can handle) to do well for myself and my family. However, being self-employed means that the more I work, the more I earn. The incentive is always there to work more. That is the biggest problem with being self-employed for me; I have the desire to always work. I am still trying to balance things so that I work less, but it’s hard. It’s even harder that I’m pouring time into ReceiptWallet where the financial reward isn’t immediate and is largely speculative. However, the potential is huge.

Also, if I’m sick, I can’t really work which means I can’t earn money. This, unfortunately, causes me a lot of stress and can cause my ulcerative colitis to flare up like it did several years ago. I just got over being sick (I was sick for about 2.5 weeks), but this time I did my best to work as much as I could and my sickness didn’t cause me stress (my desire to get all my projects done, however, did).

Working at home and being self-employed has a lot of upsides; I’m not sure I could work in an office 5 days a week. Maybe 1 or 2 would be a nice change, but never again could I do it all the time. Self-employment has a lot of scary things and lots of garbage to deal with, i.e. company taxes, company accounting, getting clients to pay, etc. However, there is no job security in any job (OK, maybe some government jobs), so being self-employed is the only way to control your own destiny. Would I work for a company again? If I said no, I’d be lying. If the numbers were right, I would say yes.

Feel free to ask me questions or comment on my thoughts.

Posted on

Does anyone at Apple actually care about us developers?

I fired up ReceiptWallet beta on a Tiger machine today to check out a problem and it didn’t launch. Huh, I looked at the crash log and it said there was a problem with a symbol not found using the dynamic linker (I’m not sure why my testers on Tiger didn’t find this as it clearly doesn’t work). So, I look at my code and I have:

	[pictureTaker setValue:[NSNumber numberWithBool:NO]
		forKey: IKPictureTakerAllowsFileChoosingKey];

This code only executes on Leopard, so it should be fine. However, whoever decided to define this constant decided to define it as such:

	extern NSString *const IKPictureTakerAllowsFileChoosingKey;

instead of something smart like:

	#define IKPictureTakerAllowsFileChoosingKey	@"IKPictureTakerAllowsFileChoosingKey"

Why is the second one smarter? Because it allows people to compile in features that work on 10.5 while still supporting 10.4. I have checks in my code to not execute this chunk of code on Leopard, so that isn’t a problem. The problem with this is that while everything compiles and links, it crashes on Tiger.

Apple wants us to use new technology, but most of us can’t abandon Tiger users, so we compile against the 10.5 SDK with a Mac OS X Deployment Target of 10.4 as indicated we should do in the Core Data Release Notes.

Apple, please fix this!

Posted on

Another set of bugs in Leopard

A number of weeks ago, I fought with Leopard to be able to use a magnetic stripe reader in one of my apps. The Apple sample code worked on Tiger, but broke on Leopard. OK, I reported that as a bug. Next, I looked at some new USB code in Leopard and that failed as well. After opening an Apple DTS incident, buying a magnetic stripe reader for them, and going round and round, they acknowledged the first bug and the second bug which was a workaround to the first one. DTS did send me code that finally did work.

This week, I fought with Leopard (or maybe it is Tiger) dealing with the Keychain. The Keychain (along with System Configuration) are some of the most confusing frameworks to write code. This weeks’ issue dealt with using the Keychain framework to get a password out of the System keychain (like for PPP passwords). If the user clicks on Always Allow, the method returns a -61 error which is a write permissions error. What’s the workaround? Well, if I get a -61 error, I put up the request again. While this gets me to the end goal, it really confuses the user.

Today was another bug dealing with the Image Capture. I wanted to add supporting Image Capture in addition to TWAIN as it might be more reliable. I got as far as implementing the UI and all the code, only to find out that if I scan once, when I close the scanner session, I get an error and then I can’t scan again. All that I’ve read indicates that the Image Capture Framework (ICA) doesn’t work properly when compiled against 10.5. This doesn’t surprise me as someone changed the TWAIN header files in Leopard so that UInt32s were changed to void * or vice versa. This, of course, causes lots of warnings that have to be typecasted. Scanning is one of those areas in the OS that doesn’t seem to get touched and no one seems to care. The scanner vendors write crappy drivers so they don’t complain and no one else is big enough to get Apple to care. Maybe things will change.

Posted on

Paying for being stupid

The recent measles outbreak here in San Diego could easily have been prevented if the parents of the original infected child had vaccinated that child. However, the parents exercised their right to not vaccinate. Some parents believe that the mercury in vaccines leads to autism; the problem with this theory is that vaccines haven’t had mercury (thimerosal) in them for years. At the same rate, autism rates have gone up, so it would lead any reasonable person to conclude that the vaccines (at least mercury in them) has nothing to do with autism.

While the parents exercised their right, their negligence (in my opinion) caused others to become infected (infants under 1 year can’t be vaccinated for measles). I think that these people should pay for the medical costs of all those infected and should pay everyone for being inconvenienced. My wife has had to change plans because our son can’t be vaccinated (he’s 9 month old). These parents’ choice has caused people all over San Diego to worry about something that I hadn’t heard of in years.

Please vaccinate your children as your decision should not put my child at risk. If you choose not to vaccinate your children, please never come out of your house.

Posted on

Planning for Aiden’s first birthday

Our son, Aiden, is rapidly approaching his first birthday. We’re trying to figure out what to do. Should we have a clown? How about a pony? How about one of those jumpy things? Wow, this is going to be huge. We’re going to spend a lot of time and money planning a party that our son will never remember! Just kidding, we’re not going overboard with his first birthday, maybe another birthday down the line, but why one that he won’t appreciate? My wife has told me that some of the mothers she has run into are planning elaborate parties for their child’s first birthday. What a waste.

Posted on

Can’t please everyone

Today, a very irate user sent me email complaining about the merging of ReceiptWallet and DocumentWallet. He wrote a very long email messages saying he felt ripped off and there is no mention of this on our website. Well, it isn’t mentioned on the website because it is in BETA and hasn’t been put into general release. There is no need to mention beta versions on our website (except for a small mention on how to get the cutting edge version).

As for being ripped off, shouldn’t people buy software for what it does today and not what it could do with an update tomorrow? Does the software stop working just because a new version comes out? Personally I think that the cost of ReceiptWallet and DocumentWallet at $44.93 (50% off the second program) is easily justified. If it saves a few hours of work, then it can be justified. I was originally going to charge $39.95 for ReceiptWallet alone, but decided to start at $29.95 and never got around to raising the price. I’ve always been clear that the products are similar and even have articles here and here explaining the differences. The products do serve different purposes when you can only have 1 library open at a time. However, with the upcoming ReceiptWallet 2.0.0, you can have more than 1 library open at a time, so the reasons I’ve given no longer apply. People have never been forced to buy both products.

I had one user that loves the beta so much that even before I decided to merge the two, but just by adding the multiple libraries, bought a second copy of the software just because he thought the product was that good. A person was willing to pay $60 for ReceiptWallet!

I’m very pleased with my decision to merge the two products and think that it will help me compete and have a better, more feature rich product.

Posted on

Bit by a linker issue

Apple has some great code to handle adding and removing items as login items called LoginItemsAE which uses AppleEvents to talk to System Preferences. I’ve used it on a number of projects and found it to work well. That was until today. A client complained that my install code wasn’t working that added it as a login item. I couldn’t reproduce this on my Mac Mini (Intel) and I use the same piece of code in another app in the same bundle and it worked fine. After a bit of fighting with the system and remembering that sometimes Carbon framework needs to be linked, I linked it in and the problem went away. Why, oh why, didn’t I get a linker error?

Posted on

Merging ReceiptWallet and DocumentWallet

After a bit of mental wrangling and taking some email to heart, I decided to merge ReceiptWallet and DocumentWallet. This means that ReceiptWallet can now open DocumentWallet libraries in addition to ReceiptWallet libraries. When you create a library, you choose for it to be a receipt or a document library. This now makes a lot more sense since multiple libraries can be open at once. The libraries still have a few things different (number stuff doesn’t make sense in a pure document library).

What does this mean for DocumentWallet? Well, DocumentWallet serial numbers will now work in the new version of ReceiptWallet. This will be a free update for all users. When this new version comes out, I will be raising the price as I have added a significant amount of functionality with the last few updates. My current price was meant to be an introductory price, but I never got around to raising it. Now is a good time to do so.

One kind of weird thing is that DocumentWallet users can’t automatically update to ReceiptWallet using the auto update mechanism because the applications are named differently and the application identifiers are different. So, users will have to download ReceiptWallet and update through that.

The new ReceiptWallet beta is available in the standard way.

Proudly powered by WordPress