If you want to replace Google Apps because of price or because of privacy there are actually tons of good choices these days. I reconciled several services and servers on Bluehost recently saving a considerable amount of money. There was a quirk that meant I couldn’t FTP at first but a quick call to tech support fixed it. And, unlike Google, there actually is tech support and they answer their phones quickly. The price is right as well at only $3.95/mo for the low tier. I paid the extra for the pro version. But that’s only $19.99/mo — less than what Google chargers per user.
I have several different hosts running on it. They’re all low volume — mostly different companies. I have a lot of archived email though. Nearly 4 gig, which was why I had been hesitant moving. However Bluehost handles it no trouble. This blog is running on it too.
About the only quibble is that by default there’s no CalDAV or CardDAV server. Personally I hate having too many of those. iCloud is enough for me and then I do one directional sync to Google Contacts via Contacts Sync for Google Gmail. I do that so I can actually find addresses quickly in Google Maps. But I do it one way so nothing gets screwed up by Google. However if you really need calendars or contacts in the cloud I was able to install Baikal in about 10 minutes just using FTP. Much easier than the OSX Server solution I’ve heard some propose.
OK this one is a bit silly. However I was curious if I could use ApplescriptObjC with Swift. Why? Mainly giggles and also to see if there was an easy way to bridge certain stuff from Applescript but do my actual scripting in Swift. The trick to calling ApplescriptObjC objects from Cocoa is to create a protocol, use NSClassFromString, instantiate from the returned class your object, and then call your method. (Which is actually an Applescript routine) The problem is that while Swift supports creating classes with NSClassFromString there’s no way to instantiate a class so returned. I played around with it a long time. The best solution is really a wrapper class in ObjC that calls the ApplescriptObjC methods that you can call from Swift.
Using Swift enums instead of KVC. There are some really fascinating gists out there for small Swift features. Also operator overloading to make a valueForKey operator in Swift. I really like the latter gist.
Edit: Brent Simmons has a post up about these now. I should note that you can use the @objc attribute or subclass NSObject to get full traditional ObjC functioning. To my eyes Swift is taking the best of both worlds of C++ and ObjC. It’s kind of like ObjC++ in that regard, but without the slow compilation. (See for example this StackOverflow discussion)
I’ve noticed a lot of people looking at what Swift is like with its default object neglecting that the compiler looks intelligently at what you are doing and chooses the best solution. So you really do get most of your ObjC features when you want them but the speed of C/C++ calling when you need those. I don’t quite understand all the gnashing of teeth at this. As Simmons notes though, a lot of these things are in flux. I wouldn’t count on Swift right now if you’re doing anything too tricky.
I said a few weeks ago that I was testing out the CRM app Daylite. I gave my original thoughts there but promised a deeper discussion of the app. I know a lot of people were curious about how my evaluation went. I’ve also had a lot of questions come my way. I have a ton of notes from my evaluation. I figured the best way to discuss the app was in terms of workflow. So I’ll have several posts each focused on a different aspect of workflow.
I did end up buying Daylite. There are a lot of frustrating aspects to the app, but I simply liked it far better than most of the alternatives. Especially when compared with web apps like Sugar CRM or Salesforce. The version I tested (5.0.3) is vastly improved over the version (3.5) I tested a few years ago. However for every great feature there is something that just leaves you scratching your head. Hopefully the developers will read these posts and perhaps adjust the app somewhat in response. I’m not saying my views are right – workflows are very personal. How I use an app is certainly not how everyone else will use it. Likewise I’m still learning the app. I apologize in advance if I complain about not being able to do something when I just am ignorant of how to do it.
These posts will be half review and half suggestions for using Daylite that I’ve found. They’ll be quite involved. I’ll try and include a few tips too. Please don’t hesitate to correct me or ask questions.
Someone’s written an other great library for Swift: Pythonic. (HT: Oluseyi on ADN) It adds most of the commonly used standard Python library to Swift.
I confess I’ve been learning Swift by recreating the Python library calls that I regularly use. Mine was definitely an exploratory work though. I was mainly working in a Playground. Half the code I deleted when I was done.
Just a quick update with how my Nissan Leaf has been going. It’s been about two months now and I’m extremely happy with it. I definitely miss driving off road with my Pathfinder. Lacking 4WD with good ground clearance made taking my daughter camping a bit more logistically challenging. However not needing to worry about gas has been a definite plus. Especially as gas heads up near $4/gallon in price.
Last week I put the Leaf to the big test of long distance driving. The Leaf, unlike most cars, is optimized for city driving not freeway driving. I had to head to Salt Lake City for business, about a 90 mile round trip and was curious if the Leaf could make it. On the drive up I was very cautious, primarily driving regular roads. About half way there I was running late and got onto the freeway. It was also well into the 90’s so I had the air conditioner running. A notable power drain. While most traffic was going 80mph on the freeway I kept the car between 65 and 70 and stayed in the slow lane. The car definitely drained charge significantly faster as I inched above the 65mph point. Fortunately my stop was only a few blocks away from a Nissan dealer where I could use their high speed Level 3 charger.
One of the things many people were excited about with iOS was 3rd party keyboards. While I think this will lead to more innovation the fact is the iOS8 keyboard is pretty fantastic on its own. Far better than any of the the 3rd party keyboards I’ve played with on Android.
I have to confess that one of the few reasons I still jailbreak is for SwipeSelection, a nice little addition that gives you cursor control via swiping. At WWDC I was really excited that this feature could be part of an unjailbroke system. There’s a bit of sad news though. I Love Swift had a good post on writing a keyboard that had a nice summary of the limits of third party keyboards.
I’d mentioned in passing in one of my Swift posts about using it as a scripting language. Someone on Twitter asked me if I’d convert from using Python to Swift for my scripts. It’s an excellent question that I really can’t answer fully at this stage. The language is still very beta. Most of the bugs I’ve submitted appeared to have been fixed but I’m somewhat loath to get too far into Swift until it gets a little more mature. Say at least beta 3 or 4. However here’s my thinking although this is somewhat preliminary. I’ve just not tried to use Swift as a practical scripting language.
So Apple released news today that Aperture is no more. You’d think they’d have learned after the Final Cut Pro mess and the iWork mess how to make these announcements. John Gordon captures well what they should have done. I think users understand that Lightroom kicked Aperture’s butt and that sales were decreasing. I think they understand that sales have dropped to near nothing with nearly all pros having already left. What they can’t accept is Apple trying to hide the news by announcing it via Jim Dalrymple’s blog with nothing prepared. Again, you’d think they’d have learned by now.
All they had to do was have Tim Cook come out, announce that because of low sales they aren’t going to be major new releases but that Apple would continue maintenance releases. Further they announce this as they have a new version with the export features so people can move to Lightroom. Trying to get metadata not to mention projects and smart albums into Lightroom is a nightmare according to those who’ve tried. The issue isn’t Apple killing a dying product. Rather the issue fundamentally is why people should trust Apple with their data when they’ve pulled this three times in a row.
Most of my scripts haven’t been updated in a while, but I try and keep the main ones on GitHub for others to use. As I make significant updates I’ll update the GitHub versions. So if you are interested in my scripts, please check out that repository. Now that Swift is becoming a bit more mature I may try doing some scripts with it in the future.