console.log("Hello World");
The HP Z Book is a great development laptop for anyone that needs to build using the Windows stack. There is one minor annoyance, by default the function keys are not mapped to your standard F1 through F12.
To fix this, press fn+ctrl+shift. The standard function key behavior will then be active.
If you need to work with email in a .NET environment I highly recommend checking out MailKit by Jeffrey Stedfast. MailKit provides a higher level abstraction working across the different email protocols, which is a massive time saver.
MailKit has its own classes for handling Email Addresses. Most notability the MailboxAddress and InternetAddressList classes are returned when parsing a message envelope.
| foreach (var summary in inbox.Fetch(0, -1, MessageSummaryItems.UniqueId | MessageSummaryItems.BodyStructure)) | |
| { | |
| var tos = summary.Envelope.To; | |
| var replyToList = summary.Envelope.ReplyTo; | |
| } |
As powerful as the MailKit constructs are, I typically like to convert any 3rd party types into their .NET framework equivalents. The below extension method adds a ToMailAddressCollection method to MailKit’s InternetAddressList class.
| public static class MailKitExts | |
| { | |
| public static MailAddressCollection ToMailAddressCollection(this InternetAddressList addressList) | |
| { | |
| if(addressList == null) | |
| { | |
| return new MailAddressCollection(); | |
| } | |
| return addressList.Mailboxes.Aggregate(new MailAddressCollection(), (c, r) => { c.Add(new MailAddress(r.Address, r.Name)); return c; }); | |
| } | |
| } |
Lately, I’ve been working on a project that requires some basic MLP text processing to be performed on device. A component of our text processing involved removing any trailing punctuation, no matter the language.
I’ve found the below String Extension is a good balance between effectiveness, performance, and readability. Especially if you are collecting input from users prone to excessive punctuation.
| extension String { | |
| func trimTrailingPunctuation() -> String { | |
| return self.trimmingCharacters(in: .whitespacesAndNewlines) | |
| .trimmingCharacters(in: .punctuationCharacters) | |
| .trimmingCharacters(in: .whitespacesAndNewlines) | |
| } | |
| } |
| let example1 = "How are you???".trimTrailingPunctuation() | |
| >>> How are you | |
| let example2 = "Hi!!!!".trimTrailingPunctuation() | |
| >>> Hi | |
| let example3 = "Act limited time offer now!".trimTrailingPunctuation() | |
| >>> Act limited time offer now |
With every release of Xcode it seems to eat more and more space. I was thrilled to find the XcodeCleaner project from Baye on Github. This is a great project that allows you to tailor the space Xcode uses. I’ve been able to free up an easy 12GB without any issues.
I highly recommend checking out the project on GitHub at XcodeCleaner. You can build the project from source or download from the macOS App Store for $0.99.
Lately I’ve been working on several projects using conversational UI or “Bot” interactions. A key interaction pattern when designing “Bots” you must listen to both the intent and sentiment of the text the user is providing. Through the use of sentiment analysis you can help determine the mood of the user. This can be an important tool in determining when to offer help or involve a human. You might think of this as the “help representative” moment we are all familiar with. Using sentiment analysis you can try to offer help before that moment occurs.
There are several great sentiment analysis node.js packages but nothing I could find to run offline in Swift. A majority of the node.js projects seem to be a forks of the Sentiment package. The Sentiment-v2 package worked best for many of my cases and became my starting point.
A majority of the sentiment analysis packages available through NPM use the same scoring approach. First they parse a provided phrase into individual words. For example “Cats are amazing” would be turned into an array of words, ie [“cats”, “are”,”amazing”].
Next a dictionary of keywords and associated weights are created. These scoring dictionary is created using the AFINN wordlist and Emoji Sentiment Ranking. In a nutshell, words like “amazing” would have a positive weight whereas words like “bad” would have a negative weight. The weight of each word in the provided phrase is added together to get the total weight of the phrase. If the phrase has a negative weight, chances are your user is starting to get frustrated or at least talking about a negative subject.
Using this approach I created the SentimentlySwift playground to demonstrate how this can be done on device using Swift. This playground uses the same FINN wordlist and Emoji Sentiment Ranking weights to determine a sentiment analysis score without the network dependency. To make comparisons easier, I tried to mirror the Sentiment package API as must as possible. The below demonstrates the output for a few of the test phrases included with Sentiment.
| let sentiment = Sentimently() | |
| print(sentiment.score("Cats are stupid.")) | |
| analysisResult(score: -2, comparative: -0.66666666666666663, positive: [], negative: ["stupid"], wordTokens: [wordToken(word: "cats", wordStem: Optional("cat")), wordToken(word: "are", wordStem: Optional("be")), wordToken(word: "stupid", wordStem: Optional("stupid"))]) | |
| print(sentiment.score("Cats are very stupid.")) | |
| analysisResult(score: -3, comparative: -0.75, positive: [], negative: ["stupid"], wordTokens: [wordToken(word: "cats", wordStem: Optional("cat")), wordToken(word: "are", wordStem: Optional("be")), wordToken(word: "very", wordStem: Optional("very")), wordToken(word: "stupid", wordStem: Optional("stupid"))]) | |
| print(sentiment.score("Cats are totally amazing!")) | |
| analysisResult(score: 4, comparative: 1.0, positive: ["amazing"], negative: [], wordTokens: [wordToken(word: "cats", wordStem: Optional("cat")), wordToken(word: "are", wordStem: Optional("be")), wordToken(word: "totally", wordStem: Optional("totally")), wordToken(word: "amazing", wordStem: Optional("amaze"))]) | |
| var testInject = [sentimentWeightValue]() | |
| testInject.append(sentimentWeightValue(word: "cats", score: 5)) | |
| testInject.append(sentimentWeightValue(word: "amazing", score: 2)) | |
| print(sentiment.score("Cats are totally amazing!", addWeights: testInject)) | |
| analysisResult(score: 7, comparative: 1.75, positive: ["cats", "amazing"], negative: [], wordTokens: [wordToken(word: "cats", wordStem: Optional("cat")), wordToken(word: "are", wordStem: Optional("be")), wordToken(word: "totally", wordStem: Optional("totally")), wordToken(word: "amazing", wordStem: Optional("amaze"))]) |
Although the APIs are similar there is one important difference between the two approaches. The SentimentlySwift playground uses NSLinguisticTagger to tokenize the provided phrase. Using NSLinguisticTagger, SentimentlySwift first parsers each word into a series of word slices. Each slice is a word tokenized using the options provided to the NSLinguisticTagger. Next the slides are enumerated and an optional “tag” or word stem is calculated. For example, in the phrase “cats are amazing”, the “amazing” word generates a word stem of “amaze”. A better example would be the word “hiking” produces the word stem of “hike”.
The following snippet shows an example on how this can be implemented.
| public struct wordToken { | |
| let word: String | |
| let wordStem: String? | |
| init(word: String, wordStem: String?) { | |
| self.word = word | |
| self.wordStem = wordStem | |
| } | |
| } | |
| func lemmatize(_ text: String) -> [wordToken] { | |
| let text = text.lowercased() | |
| let options: NSLinguisticTagger.Options = [.omitWhitespace, .omitPunctuation, .omitOther] | |
| let tagger = NSLinguisticTagger(tagSchemes: NSLinguisticTagger.availableTagSchemes(forLanguage: "en"), | |
| options: Int(options.rawValue)) | |
| tagger.string = text | |
| var tokens: [wordToken] = [] | |
| tagger.enumerateTags(in: NSMakeRange(0, text.characters.count), scheme: NSLinguisticTagSchemeLemma, options: options) { tag, tokenRange, _, _ in | |
| let word = (text as NSString).substring(with: tokenRange) | |
| tokens.append(wordToken(word: word, wordStem: tag)) | |
| } | |
| return tokens | |
| } |
You might be asking why this is important? By implementing Lemmatisation you increase your AFINN hit rate and improve your overall analysis scoring.
This is one trick I’ve found for improving or at least monitoring your conversational UI or “Bot” interactions.
Fastlane is one of the tools that a developer shouldn’t live without. At this point it must have saved me hundreds of hours. As great as fastlane is out of the box it has a few rough edges when you introduce a WatchKit app.
Recently I added a WatchKit app into one of my projects and started getting the below error:
In a nutshell, Apple requires that your WatchKit app and it’s companion app share the same version. If your fastlane build includes increment_build_number these will never match by default.
Solving this problem is pretty easy, although alittle more involved then just changing your versioning system like in your core app. Hopefully the below will help people Googling for this error in the future.
The first thing you will need to do is update the versioning configuration for your Watch App’s target.
With these changes in place fastlane increment your Watch App’s Current Project Version every time increment_build_number is called. This will work just like it does in your core app target.
Just like step 1, you will need to update the versioning configuration for your Watch App’s extension target.
This again let’s fastlane increment your Watch App’s Extension when increment_build_number is called.
If you run your fastlane build process now you will notice you still get an error that your CFBundleVersion information does not match. Whereas fastlane is updating the Current Project Version in both your Watch App and Watch App Extension it doesn’t update their CFBundleVersion value.
The best way I’ve found to do this is to use PlistBuddy and update the CFBundleVersion as part of the fastlane build process. Below is a small convenience function created to manage the process of updating the build numbers.
| def setBuildNumberOnExtension(build_number) | |
| raise if build_number.nil? | |
| puts "Setting Extension to build number #{build_number}" | |
| sh("/usr/libexec/PlistBuddy -c 'Set CFBundleVersion #{build_number}' ../myWatchApp/Info.plist") | |
| sh("/usr/libexec/PlistBuddy -c 'Set CFBundleVersion #{build_number}' ../myWatchAppExtension/Info.plist") | |
| end |
For my workflow I’ve incorporated the setBuildNumberOnExtension helper function into my build method that is called as part of my deployment, testing, or CI process.
| desc "Create ipa" | |
| lane :build do | |
| increment_build_number | |
| setBuildNumberOnExtension( | |
| get_build_number | |
| ) | |
| gym(scheme: "TestApp", workspace: "TestApp.xcworkspace", output_directory: "../../../Builds/TestApp", clean:true, silent: true, export_method: "enterprise") | |
| end |
The same approach should work for all extensions. Even if you only have a “Today Extension” I’d recommend keeping the version numbers in sync with your core app. This will make life easier when you are debugging.
Check of the fastlane examples for more ideas on how to create extensions to improve your workflow.
How often do you convert a UIImage into a Data object? Seems like a relatively straight forward task, just use UIImageJPEGRepresentation and your done.
After doing this I started seeing memory spikes and leaks appear which got me thinking on how I can better profile different options for performing this conversion. If you want to follow along you can create your own Swift Playground using this gist.
The first step was looking at the different ways you can convert a UIImage into Data. I settled on the following three approaches.
Out of all the options this is the most straightforward and widely used. If you look at the testing blocks later in the post you can see I’m simply inlined the UIImageJPEGRepresentation with the test suite compression ratio.
| UIImageJPEGRepresentation(image, compressionRatio) |
Out of the box UIImageJPEGRepresentation provides everything we need. In some cases I’ve found it holds onto memory after execution. To determine if wrapping UIImageJPEGRepresentation in a autoreleasepool has any benefit I created the convenience method UIImageToDataJPEG2. This simply wraps UIImageJPEGRepresentation into a autoreleasepool closure as shown below. We later use UIImageToDataJPEG2 within our tests.
| func UIImageToDataJPEG2(image: UIImage, compressionRatio: CGFloat) -> Data? { | |
| return autoreleasepool(invoking: { () -> Data? in | |
| return UIImageJPEGRepresentation(image, compressionRatio) | |
| }) | |
| } |
The ImageIO framework gives us a lower level APIs for working with images. Typically ImageIO has better CPU performance than using UIKit and other approaches. NSHipster has a great article with details here. I was interested to see if there was a memory benefit as well. The below helper function wraps the ImageIO functions into an API similar to UIImageJPEGRepresentation. This makes testing much easier. Keep in mind you’ll need to have image orientation yourself. For this example we just use Top, Left. If you are implementing yourself you’ll want read the API documentation available here.
| func UIImageToDataIO(image: UIImage, compressionRatio: CGFloat, orientation: Int = 1) -> Data? { | |
| return autoreleasepool(invoking: { () -> Data in | |
| let data = NSMutableData() | |
| let options: NSDictionary = [ | |
| kCGImagePropertyOrientation: orientation, | |
| kCGImagePropertyHasAlpha: true, | |
| kCGImageDestinationLossyCompressionQuality: compressionRatio | |
| ] | |
| let imageDestinationRef = CGImageDestinationCreateWithData(data as CFMutableData, kUTTypeJPEG, 1, nil)! | |
| CGImageDestinationAddImage(imageDestinationRef, image.cgImage!, options) | |
| CGImageDestinationFinalize(imageDestinationRef) | |
| return data as Data | |
| }) | |
| } |
UIImagePNGRepresentation is great when you need the highest quality image. The side effect of this is it has a largest Data size and memory footprint. This disqualified UIImagePNGRepresentation as an option for these tests.
For my scenarios it was important to understand how memory is impacted based on the following:
Image quality is an important aspect of my projects, so the tests where performed using the compression ratios of 1.0 and 0.9. These compression ratios where then run using 1, 2, 14, 20, and 50 executions. These frequencies demonstrate when image caching and Autorelease Pool strategies start to impact results.
I test each of the above mentioned approaches using the template outlined below. See the gist of the details for each approach.
There is some variability on how each approach is tested.
The implementation for each approach is slightly different, but the same iteration and compression ratios are used to keep the outcome as comparative as possible. Below is an example the strategy used to test the JPEGRepresentation with Autorelease Pool approach.
| func Test_JPEGRepresentation_AutoRelease(iterations: Int, compressionRatio: CGFloat,image: UIImage) { | |
| //Gather the initial information | |
| let startReading = report_memory() | |
| print("Memory at start: \(startReading / 1024 / 1024) mb") | |
| //Loop through the number of test iterations specified | |
| for index in 1...iterations { | |
| if let data = UIImageToDataJPEG2(image: image, compressionRatio: compressionRatio) { | |
| //Sample the length of the first result to make sure we are comparing the same size | |
| if index == 1 { | |
| //Report out results | |
| let dataSize = Int(data.count / 1024 / 1024) | |
| print("Data Length: \(dataSize) mb") | |
| } | |
| } | |
| } | |
| let endReading = report_memory() | |
| print("Memory at finish: \(Int(endReading / 1024 / 1024)) mb") | |
| let delta = (Int(Int(endReading) - Int(startReading)) / 1024 / 1024) | |
| print("Memory delta: \(delta) mb") | |
| } |
Below is the result broken down by iteration.
I am sure there is a ton of optimizations that could be made to bring these numbers down. Overall the usage of UIImageJPEGRepresentation wrapped within an Autorelease Pool looks to be the best approach. There is more work to be done on why the compression ratio has an inconsistent impact, my guess is this is a result to caching within the test.
Although the ImageIO strategy was better in a single execution scenario I question if the proper handling of image orientation would reduce or eliminate any of your memory savings.
There are more comprehensive approaches out there. This is just an experiment using Playgrounds and basic memory sampling. It doesn’t take into account any memory spikes that happen outside of the two sampling points or any considerations around CPU utilization.
The default behavior is for your tap or other gestures to bubble up to their child controls. This avoids the need to add a recognizer on all of your child controls. But this isn’t always the behavior you are looking for. For example imagine you create the below modal view. You want to add a tap gesture recognizer to the view itself so when your user taps the grey area it closes the modal. But you don’t want the gesture to be triggered when a tap is made on the content UIView of the modal.
For our use case the first thing we need to do is add a UITapGestureRecognizer to the root UIView of the UIViewController. This will close our UIViewController when the grey area is tapped.
| internal class ConfirmationViewController: UIViewController { | |
| override func viewDidLoad() { | |
| super.viewDidLoad() | |
| let tap = UITapGestureRecognizer(target: self, action: #selector(self.handleTapOffModal(_:))) | |
| tap.delegate = self | |
| view.addGestureRecognizer(tap) | |
| view.isUserInteractionEnabled = true | |
| } | |
| } |
So that the UITapGestureRecognizer isn’t triggered when a tap is made to the content UIView we simply need to add protocol method to restrict the tap to the view it is associated with.
| extension ConfirmationViewController: UIGestureRecognizerDelegate { | |
| func gestureRecognizer(_ gestureRecognizer: UIGestureRecognizer, shouldReceive touch: UITouch) -> Bool { | |
| return touch.view == gestureRecognizer.view | |
| } | |
| func handleTapOffModal(_ sender: UITapGestureRecognizer) { | |
| dismiss(animated: true, completion: nil) | |
| } | |
| } |
Below is the full code associated with the modal UIViewController. If you are not familiar with how to create a modal UIViewController I would recommend checking out Tim Sanders tutorial here.
| import UIKit | |
| internal class ConfirmationViewController: UIViewController { | |
| override func viewDidLoad() { | |
| super.viewDidLoad() | |
| let tap = UITapGestureRecognizer(target: self, action: #selector(self.handleTapOffModal(_:))) | |
| tap.delegate = self | |
| view.addGestureRecognizer(tap) | |
| view.isUserInteractionEnabled = true | |
| } | |
| } | |
| extension ConfirmationViewController { | |
| @IBAction func cancel_click(_ sender: Any) { | |
| dismiss(animated: true, completion: nil) | |
| } | |
| @IBAction func confirm_click(_ sender: Any) { | |
| print("Perform Confirmation action") | |
| dismiss(animated: true, completion: nil) | |
| } | |
| } | |
| extension ConfirmationViewController: UIGestureRecognizerDelegate { | |
| func gestureRecognizer(_ gestureRecognizer: UIGestureRecognizer, shouldReceive touch: UITouch) -> Bool { | |
| return touch.view == gestureRecognizer.view | |
| } | |
| func handleTapOffModal(_ sender: UITapGestureRecognizer) { | |
| dismiss(animated: true, completion: nil) | |
| } | |
| } |
Having your device automatically back-up to iCloud is one of the better services Apple provides.
Although not new, iCloud (introduced in June of 2011) back-up is one of the better services Apple has rolled out. If used right this removes a whole class of end user data lose fears.
However as an app developer you need to take this into consideration. Where it is privacy, size constraints, or other you need to be aware what you might be sending to iCloud.
You might wish to not back-up specific files. To do this you must set the file’s isExcludedFromBackup attribute to true. Below is a helper method to help get you started.
| struct FileHelpers { | |
| @discardableResult static func addSkipBackupAttribute(url: URL) throws -> Bool { | |
| var fileUrl = url | |
| do { | |
| if FileManager.default.fileExists(atPath: fileUrl.path) { | |
| var resourceValues = URLResourceValues() | |
| resourceValues.isExcludedFromBackup = true | |
| try fileUrl.setResourceValues(resourceValues) | |
| } | |
| return true | |
| } catch { | |
| print("failed setting isExcludedFromBackup \(error)") | |
| return false | |
| } | |
| } | |
| } |
I think everyone, at least developers, have at least one iCloud account which is linked to an old email address. To address this I’ve been migrating mine over to another domain. The process is extremely easy, just visit appleid.apple.com and change your Apple ID email address.
Although easy, this can be a real pain as you will need to enter your new details 10x times per device. Annoying but worth the effort to clean up your accounts.
I thought I was all set until I ran into an issue on macOS. Since I didn’t sign out of iCloud on macOS before changing my Apple ID email it wouldn’t let me sign out. I figured there had to be information on how to force a logout on Stackoverflow or the Apple forums. But, after multiple searches I wasn’t able to find a solution that simply allowed me to sign out. I decided to look if there was any tweaks to defaults which could help.
After a few attempts I found a solution. If you ever run into this problem, you can simply do the following:
You should now be able to go into System Preferences, iCloud and see the below iCloud login prompt.
bencoding 