# Miguel Quinones Software engineering thoughts This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## My top 5 must-have technical books DevFeed: [My top 5 must-have technical books]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2018-01-28T19:06:09Z Content type: opinion Language: en Sources: [Miguel Quinones]() Topics: [Programming](), [Testing](), [Domain-driven design (DDD)](), [Unit testing](), [Software](), [Algorithms, Complexity]() Tags: [books](), [complexity](), [modelling](), [opinion](), [programming](), [technical](), [testing]() ### AI overview The article recommends five technical books for software engineers, especially junior engineers: The Pragmatic Programmer, The Art of Unit Testing, Seven Languages in Seven Weeks, Domain-Driven Design, and The Algorithm Design Manual. It highlights self-improvement, maintainable tests, programming-language paradigms, software modeling, complexity, and algorithmic problem solving. ### Source excerpt Quite recently a team member wanted to suggest interesting technical books to read for a junior engineer. I figured I might as well write my top 5 books here, in no particular order. I believe every Software Engineer should own these books, but reading them is a very good start ;) The Pragmatic Programmer: From journeyman to master If you have to read just one book, specially when starting to write software, it should be The Pragmatic Programmer. It covers ideas, always focused on self-improvement, mastery of the craft, and professinalism. I see this book as an extended list of ideas and suggestions for self-improvement, similar to the programmer competency matrix. While reading it, it's better to keep growing a list of topics to investigate further, as the book covers wildly different practices, ideas, and techniques. The Art of Unit Testing This book opened my eyes into the world of unit testing, from a practical (not philosophical) point of view. It introduced me to practical techniques to use in unit testing. Most imporptantly, it helps understand the crucial understanding of the necessity of maintainable test code, and 'good' tests. I think it's the best introductory book on unit testing. Period. Seven Languages in Seven Weeks More than a book, "Seven Languages in Seven Weeks" is an exploration into wildly different concepts across programming languages. It's a book about paradigms, and crucially, sparks the curiosity of why these exist at all. The way that the concepts are introduced, focusing on the reasons, advantages, disadvantages and design decisions of a language were very insightful for me. If you don't try the proposed challenges the book still will give you a lot of material to think about and to take ideas from. Domain-Driven Design Most software projects are about tackling complexity, and I must say many projects fail in this regards. The book taught me how to think about the act of writing code in a more abstracted way, as a modelling problem. Eric ## Fixing autocompletion on mixed Objective-C and Swift projects DevFeed: [Fixing autocompletion on mixed Objective-C and Swift projects]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2017-06-16T22:55:27Z Content type: tutorial Language: en Sources: [Miguel Quinones]() Topics: [Swift](), [code-completion](), [Xcode](), [Objective-C](), [debugging](), [Library]() Tags: [code-completion](), [debug](), [debugging](), [latest-release](), [libraries](), [objective-c](), [swift](), [xcode]() ### AI overview This article explains intermittent Swift code-completion failures in mixed Objective-C and Swift projects using Xcode 8 or Xcode 9 beta. It attributes the problem to library classes imported without their framework or library path, which can prevent SourceKit from indexing correctly. The article recommends including the path in bridging-header imports and describes using Xcode's debug mode and SourceKit service logs to investigate the issue. An update says the problem appeared to be fixed in Xcode 9.0.1. ### Source excerpt This year I had the privilege of attending WWDC for the first time. I knew the labs were very important, and I want to share a resolution to fix a problem for our big project at Peak: Autocompletion on Swift code was not working most of the time in the IDE, and with the help of an Apple engineer in the labs we got it sorted. Update on 30/10/2017: The issues described here seem to be fixed with latest release version of Xcode 9.0.1 (9A1004). Also the 'internal' menu doesn't seem to be accessible anymore. If you know how to access it I'd love to hear from you! The issue If you are using Xcode 8 or Xcode 9 (beta 1 as of this writing), when you have a project with mixed Objective-C and Swift, you might encounters problems with autocompletion inside the Swift code. We've had this intermitently and most recent IDE versions made work very difficult as we would not have any autocompletion for our Swift code, or it would work intermitently. Our gut feeling was that the bridging header had some classes that were causing SourceKit to fail, but we didn't know how to debug the issue nor provide good feedback for Apple to fix it. Our chance came while visiting the labs at the conference, and a very helpful and patient Apple engineer worked with our project to understand what was wrong. Bridging header imports It turns out that if you import classes from libraries (in our case using CocoaPods) omitting the path may result in Sourcekit unable to index properly. For example, a class in some library: #import "MyClass.h" Code will compile fine but your code completion in Swift side might break because the indexer fails when encountering this file. I'm still unsure if it's because of importing the file somewhere else differently or if it's just a bug in the indexer. Anyway, the way to work around it (Apple is supposedly aware of this) is to import with the framework or library style, including the path: #import "path-to-library/MyClass.h" How to debug The engineer kindly made a wrote u ## Automatic bridging from Swift to Objective-C using Sourcery DevFeed: [Automatic bridging from Swift to Objective-C using Sourcery]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2017-05-21T21:30:00Z Content type: tutorial Language: en Sources: [Miguel Quinones]() Topics: [Swift](), [Objective-C](), [Code](), [Code generation](), [Programming]() Tags: [bridging](), [code-generation](), [examples](), [generate](), [objective-c](), [programming](), [swift]() ### AI overview This tutorial explains how to automate bridging Swift structs and enums to Objective-C using Sourcery templates and metadata from production code. It introduces a protocol-based opt-in approach, describes separate generation strategies for structs and enums, and notes the use of Stencil for template development. ### Source excerpt I recently read a great post by Benjamin Encz about bridging Swift to Objective-C by creating bridging types that can be exposed to the older language. I wondered if his idea can be improved and automated using meta-programming with Sourcery by Krzystof Zablocki. The answer is a very impressive ObjC-like uppercase YES. First of all, you should read Benjamin's post. He proposes to use a bridging class that can be instantiated from Objective-C and Swift because it inherits from NSObject. The bridging class has properties to get and set the properties of the bridged type. In this post I'm just going to give an overview of the template and highlight the simpler parts. If you want to jump directly in the code, here's the project, and the template. The example template bridges struct and enum, but doesn't handle custom protocols to keep it as simple as possible. About Sourcery Sourcery is a tool to generate code, using your written templates, using metadata from your production code. In other words, it's a tool to do metaprogramming in Swift. If you are not familiar with Sourcery I encourage you to go read the documentation and at least understand the simple examples like generating Equatable implementations for your types. Getting familiar with Stencil, one of the supported template languages is also fundamental. Building the template We'll need to generate a new class for every struct and enum that we bridge. In order to opt-in to the feature, we use phantom types in order to mark swift types (our custom structs or enums) that can be bridged to Objective-C. Our template will use this protocol to which types to introspect: 1 protocol AutoObjCBridgeable {} For example, take Benjamin's example code: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 enum CheckoutOption { case creditCard(given: Int) case paypal(String) } struct ShoppingCart { var items: [String] var checkoutOption: CheckoutOption? init(items: [String], checkoutOption: CheckoutOption? = nil) { self.items = items self.checkout ## Build settings depending on Xcode version DevFeed: [Build settings depending on Xcode version]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2017-01-29T23:26:54Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Xcode](), [configuration](), [Swift](), [Code]() Tags: [bridging](), [build](), [code](), [compiler](), [configuration](), [project](), [swift](), [xcode]() ### AI overview The article explains how to use xcconfig files and the XCODE_VERSION_MINOR build setting to apply different Swift build settings for different Xcode versions. Its example enables precompiled bridging headers in Xcode 8.3 beta while preserving compatibility with Xcode 8.2.1. ### Source excerpt This weekend I wanted to setup Precompiled Bridging Headers for my project. This setting is available in the new Xcode 8.3 beta. Then building for latest official XCode (8.2.1) the code will not compile because the Swift compiler doesn't recognize it. How do we use different build settings for different Xcode versions? Only possible with xcconfig files. There's an undocumented build setting called XCODE_VERSION_MINOR that we can use here. And after some variable substitution we'll make it work. Here's the gist: 1 2 3 4 5 6 // Setting for last Xcode OTHER_SWIFT_FLAGS_XCODE_0820 = // // Setting for Xcode Beta OTHER_SWIFT_FLAGS_XCODE_0830 = -enable-bridging-pch // Switch configuration based on Xcode version OTHER_SWIFT_FLAGS = $(OTHER_SWIFT_FLAGS_XCODE_$(XCODE_VERSION_MINOR)) Full credit to Samantha Marshall's excellent writeups of xcconfig files. Take a read, very useful to refer to. ## Reducing the pain of git bisect with Xcode DevFeed: [Reducing the pain of git bisect with Xcode]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2017-01-22T11:49:01Z Content type: tutorial Language: en Sources: [Miguel Quinones]() Topics: [Git](), [Xcode](), [iOS](), [debugging](), [Mobile]() Tags: [bug](), [debugging](), [dependencies](), [git](), [ios](), [ios-development](), [xcode]() ### AI overview This article explains how Git bisect can identify regressions by performing a binary search through repository history. It focuses on reducing the friction of using bisect in iOS projects with CocoaPods and Xcode, including dependency installation, manual reproduction, device testing, app reinstallation, and repeated Xcode indexing. It begins describing automation that closes Xcode, updates dependencies, and reopens Xcode after each bisect step. ### Source excerpt There's times when you need to investigate regressions in your project, and you don't know have any clue as why something is happening. Git bisect is the best tool for this cases, but it can be painful to use in non small projects using CocoaPods and Xcode. I want to share what I've been doing to ease the pain. If you never used Git bisect, check this introduction. The git command performs a binary search across your repository history, starting from two known commits you provide to the algorithm: 'Good' and 'Bad'. 'Bad' will usually be your last commit, and 'Good' will be a commit back in the history of your repository, when you know the code was working as expected. For every step of the search you need to tell git if a commit is good or bad, either manually or automatically by running a script. Pain points When we enter the realm of iOS development, there's a some factors that make bisect tedious to use. If you use CocoaPods, and if you don't check in the 'Pods' directory in source control, every time you change branch or bisect selects a new commit, you might need to run pod install in order to have all dependencies available and compile correctly. If you are searching for a regression, chances are you don't have an automated test suite, so you'll need to run your app manually and reproduce the issue you are searching for. There will be cases when you're dealing with a bug that needs an app reinstall or needs to run on device to reproduce. To top all this, Xcode will start the long indexing process every time there's changes to the sources due to change of commit, so your computer will start doing lot of work. All of these nuances makes the process of searching for issues using bisect very tedious and not so 'magical' as it is supposed to be. I've nevertheless used bisect many times to save time otherwise wasted reading code and navigating breakpoints during long debugging sessions. You just need some patience and the will to automate some stuff. Reducing the pa ## App extensions, Xcode and Cocoapods, OMG! DevFeed: [App extensions, Xcode and Cocoapods, OMG!]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2016-11-28T09:44:54Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [App](), [Extension](), [Xcode](), [Library](), [Tooling](), [Code]() Tags: [app](), [apple](), [cocoapods](), [extensions](), [ios](), [library](), [swift](), [tooling](), [xcode]() ### AI overview This article explains compilation and integration problems that can occur when sharing CocoaPods libraries between an iOS app and an app extension. It covers APIs unavailable to extensions, conditional compilation, extension-specific code paths, and CocoaPods target deduplication. ### Source excerpt Have you encountered this error when upgrading to the latest CocoaPods (1.1.0), or sharing a library between your iOS App and your extension? 1 'sharedApplication' is unavailable: not available on iOS (App Extension) - Use view controller based solutions where appropriate instead. If yes, continue reading, as you might have encountered same issue as myself. I've recently had to upgrade a project to using Cocoapods 1.1.0. Things stopped compiling, and I had to investigate the root cause of the problem. It has to do with iOS App extensions, unavailable APIs and how fragile our tooling is ;). TL;DR The first cause of error can be fixed by conditionally compiling with a macro. See example here It's better if you define whole classes or API unavailable using NS_EXTENSION_UNAVAILABLE_IOS If you had this error in a 3rd party library you'll need it to be fixed by the author (see below) If you are a library author and need to have different code paths via preprocessor macros, read this thread, and follow the recommendation to create a separated subspec for an extension target Unavailable API for App extensions Since the introduction of Application extensions several years ago, Apple has marked some API as unavailable for these targets. For example, sharedApplication from UIApplication: 1 @property(class, nonatomic, readonly) UIApplication *sharedApplication NS_EXTENSION_UNAVAILABLE_IOS("Use view controller based solutions where appropriate instead."); or in Swift: 1 2 @available(iOSApplicationExtension, unavailable) open class var shared: UIApplication { get } Apple is using a new macro, NS_EXTENSION_UNAVAILABLE_IOS to mark API as unavailable. There's a new setting on Xcode, APPLICATION_EXTENSION_API_ONLY, and if set, the code will not compile if it contains a call to sharedApplication. This setting is automatically enabled for extension targets so you get the error in your code when you are writing it. Writing separate code for an App target and and extension target is not ## Easy localization management with Google spreadsheets DevFeed: [Easy localization management with Google spreadsheets]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2016-11-19T16:50:18Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Localization (l10n)](), [Automation](), [Google](), [Swift](), [Database](), [API](), [JSON](), [Web](), [Content Management System]() Tags: [api](), [automation](), [ci](), [database](), [google](), [json](), [swift](), [web]() ### AI overview This article explains how to manage application localizations with Google spreadsheets, a local or CI script, and Swift. The workflow uses spreadsheet data to generate localized string files while improving collaboration with translators. ### Source excerpt Last thursday I gave a talk at NSLondon meetup called 'Minimum Viable Tooling'. The topic was examples of approaching tooling and automation for small teams. I showed real examples of what we do at Peak, where I currently work. One of the things people showed interest in after the talk was how we deal with localizations. In this post I will replicate the simple solution from scratch, so you can follow along and get started with your own projects. And we will be using Swift for the scripting, just because we can! The minimal CMS In the talk I showed what we currently use to automate generation of strings at Peak. The goal of the solution is twofold: The first is to remove manual manipulation of local strings files by developers. The second is to raise visibility of any translation across the company and enable easier collaboration with translators. This is generally achieved by using a CMS, either a built solution or your own. We'll build our own by leveraging Google spreadsheets as a database and web interface. So we'll need two simple parts: One one side, the strings are hosted in a Google spreasheet. Then on the other side, we'll run a script locally or on our CI every time we want to update strings in the application. The script will load the spreasheet contents, and generate the appropiate .strings file contents. The spreadsheet I've created an example spreadsheet here. It contains rows with keys, and columns with the supported language keys in your app: Here you can take two approaches for your script; you can either use any Google spreadsheet library for a popular scripting language like Ruby or Python, or you can leverage yet another service on top of spreasheets: Sheetsu. Using the service means you don't need any library because it converts the content to a JSON API that can be easily parsed with traditional code. We'll use this as it's the simplest solution. Note that we would need to pay to have more flexibility as the free plan only allows one spreadshee ## Controlling time in the app DevFeed: [Controlling time in the app]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2016-10-26T18:38:37Z Content type: tutorial Language: en Sources: [Miguel Quinones]() Topics: [App](), [Testing](), [iOS](), [Swift](), [Library](), [Code](), [simulator]() Tags: [app](), [debugging](), [ios](), [library](), [simulator](), [swift](), [testing](), [tests]() ### AI overview The article explains how to control an application's perceived system date and time to make time-dependent behavior easier to test and debug. It presents dependency injection for unit tests and describes using the TUDelorean library with an in-app debugging menu to simulate time changes and system-triggered events without changing the device or computer clock. ### Source excerpt Today I want to share a small utility we've been using for a while at Peak, my current workplace, to control the system time inside the application and save time while testing or debugging. In most application code you'll eventually end up with tasks that need to execute periodically, or after some time has passed. The period of time will depend on the actual application requirements, and might change from the order of seconds to days. For example, you might have a data cleanup every 30 days, your application might ping a backend for synchronization every 10 minutes, or by the start of every day, some data needs to be generated and presented to the user. Foundation and dates You'll eventually use NSDate and NSCalendar (or Date and Calendar in Swift) to calculate when your tasks should be executed. As an example, say you have a task scheduler, and it will run tasks after a specific amount of time passed: 1 2 3 4 5 6 7 8 9 10 11 12 13 protocol Task { func execute() } class Scheduler { func schedule(_ task: Task, every: TimeInterval) { // Schedule and save task to run every x seconds } func run(with date: Date) { // Actually perform the calculations and fire due tasks } } For this code to be testable it's a very common practice to pass the Date in, as we do in the example above. This will improve testability as the date can be controlled from unit tests, thus isolating the system date from the date the component uses to operate. But what about the times when you want to check the integration between the code and the system date? What if you want to trigger code that reacts to UIApplicationSignificantTimeChange? The traditional way to test this kind of interactions is to change the date on the device, be it on iOS directly, or you or computer if running the simulator. But it would be very useful to control the system date and time inside the application without having to change the system date in the device or your computer. Time travel To control the time from a debugg ## Knowing when to delete code DevFeed: [Knowing when to delete code]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2016-08-16T20:04:04Z Content type: opinion Language: en Sources: [Miguel Quinones]() Topics: [Code](), [Development](), [Application Development](), [Refactoring](), [Software]() Tags: [code](), [development](), [legacy-code](), [refactor](), [refactoring](), [regression](), [rewrite](), [tests]() ### AI overview An opinion article about deciding when to delete code in long-term projects. It discusses short-lived application code, how evolving products can make code legacy, and the trade-off between refactoring and rewriting, favoring small refactorings over large rewrites. ### Source excerpt Much of the literature and writing related to sofware development focuses on the creation, new ideas, fresh ideas and things to improve in your next project. But when is it a good moment to delete the old stuff in an long term project? Here's my short rant about this; I recently deleted a chunk of code in my current project and just felt I wanted to write my thoughts. Short-lived code Working on application development field, it is very normal that some code is very short lived. If you're looking to build systems and generic components then you're generally out of luck. Most Application code is generally short lived. In my opinion we just need to know how to deal with it. Products evolve, ideas and markets change, and the code implementing those concepts has to change to reflect the direction of an application. If your code doesn't closely relate or express the domain of your application, you're bound to have design problems, miscomunication and likely many bugs. Application code is very likely to become legacy in a very short time. That time might be even less than 1 or 2 years. Legacy code There isn't consensus on what makes code reach the dreaded legacy status. The definition has changed since it's first introduction, and nowadays we generally consider legacy the code that we didn't write. See the wikipedia entry: ...source code inherited from someone else and source code inherited from an older version of the software Or another definition: Michael Feathers introduced a definition of legacy code as code without tests, which reflects the perspective of legacy code being difficult to work with in part due to a lack of automated regression tests Many programmers generally call legacy code anything that they didn't write. While this is a very harsh treament of somebody's effort and time, it will mean that your code will become legacy in very short time as well. Refactoring vs Rewriting Legacy code is often mentioned when refactoring. The effort of writing some piece o ## Xcode 8: New build settings and analyzer improvements DevFeed: [Xcode 8: New build settings and analyzer improvements]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2016-07-31T20:50:16Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Xcode](), [Compiler](), [Objective-C](), [Swift]() Tags: [build](), [compiler](), [deprecated](), [false-positives](), [improvements](), [objective-c](), [xcode]() ### AI overview This article reviews Xcode 8's new build settings and static analyzer improvements. It covers stricter nullability checking for legacy Objective-C code, deallocation analysis, Swift conditional compilation through SWIFT_ACTIVE_COMPILATION_CONDITIONS, warning-related Swift settings, and the deprecation of EMBEDDED_CONTENT_CONTAINS_SWIFT. ### Source excerpt I always like to check the new build settings and analyzer improvements of every Xcode release. And this year's main release includes a couple of goodies. Let's check them out! Analyzer improvements From the current Xcode 8 beta 3 release notes: 'Misuse of null' or CLANG_ANALYZER_NONNULL The static analyzer check for nullability violations supports both aggressive and less aggressive levels of checking. The more aggressive level checks for nullability violations in all calls This is a very nice addition for anybody dealing with legacy Objective-C code and audited APIs. So remember to enable the more aggressive setting in your project as it won't be enabled after your upgrade. Most likely you'll find that some APIs were not used correctly, and you'll get more warnings. You should set it to YES instead of YES_NONAGRESSIVE for the most strict checking. Remember you can revert (hopefully temporarily) to YES_NONAGRESSIVE so you can make your code compile while you audit the analyzer warnings again. New setting: CLANG_ANALYZER_OBJC_DEALLOC The clang static analyzer now checks for improper cleanup of synthesized instance variables in -dealloc methods Possibly a minor one, but remember that the analyzer could give you new false positives in legacy code. I couldn't make it trigger in a test project, so I don't really know what it will warn you about. New build settings New setting: SWIFT_ACTIVE_COMPILATION_CONDITIONS "Active Compilation Conditions" is a new build setting for passing conditional compilation flags to the Swift compiler. Previously, we had to declare your conditional compilation flags under OTHER_SWIFT_FLAGS, remembering to prepend "-D" to the setting. For example, to conditionally compile with a MYFLAG value: 1 2 3 #if MYFLAG // do stuff #endif The value to add to the setting -DMYFLAG Now we only need to pass the value MYFLAG to the new setting. Time to move all those conditional compilation values! New settings: SWIFT_SUPPRESS_WARNINGS and SWIFT_TREAT_WARNING ## Dear SDK developer DevFeed: [Dear SDK developer]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2016-04-22T11:50:32Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [SDKs](), [Documentation](), [Open Source](), [changelog](), [migration](), [GitHub]() Tags: [changelog](), [developer](), [documentation](), [how-to](), [migration-guide](), [open-source](), [sdk]() ### AI overview The article presents a checklist for SDK developers based on what application developers need when integrating third-party code. It emphasizes thorough documentation with examples, rationale, and FAQs; open-sourcing the SDK to support debugging and community contributions; changelogs that explain changes; and migration documentation for breaking API changes. ### Source excerpt As an application developer I get to use many third party code to integrate it into my current project. I want to share a checklist of things a user of an SDK really appreciates. Documentation This is the most important part of any SDK, be it open source or closed source. Users don't need to understand your code, or learn by themselves how to use your APIs. Maintaining documentation is a big part of maintaining an SDK, and it goes far beyond documenting the code. Documentation! Really, this is very important and lacking on many commercial SDKs. Please include examples, rationale and FAQ. Documentation!! Don't get it? Just some examples of great additional documentation: Quick: Quick RxSwift: RxSwift YapDatabase: YapDatabase Please, open source your SDK There's nothing more annonying than encountering bugs or unexpected behaviour and having to skim through logs, documentation and trial and error tests. This can happen anytime when using unfamiliar APIs, and having the source to understand what goes wrong is the first big benefit of open source SDKs. Furthermore, if you accept contributions from the community, you might get some developers helping with debugging and fixing issues. Having open issue discussions help with questions and faster communication. A good example is projects on Github. See an example of Snowplow devs just guiding me over my confusion. Surely your business model is not dependant on you not publishing the source code that interacts with your platform? Changelogs Any developer including third party code in an application is assuming the quality of your code into theirs. They also have the final accountability for the end users, who don't care where a bug or crash is coming from. Good engineering practice will make users of your SDK wary of changes you introduce, so a changelog is very important to let them know what changed. And please, don't just add stability improvements. Version migration documentation More documentation! This is very special ## Xcode 7.3 analyzer improvements DevFeed: [Xcode 7.3 analyzer improvements]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2016-01-21T20:39:53Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Xcode](), [Objective-C](), [Compiler]() Tags: [apple](), [compiler](), [improvements](), [objective-c](), [xcode]() ### AI overview The article examines new Xcode 7.3 static analyzer settings for detecting nonnull violations, Objective-C generics misuse, and missing localizability. It also notes which checks are enabled by default and demonstrates the localized-string warning. ### Source excerpt The latest xcode beta is available for downloading. There are many improvements, and the usual problems with stuff that stops working... Ah the love of Apple for it's developers :). But I want to tell you about a feature that caught my attention: New analyzer settings! New analyzer settings From the release notes: The static analyzer warns when nil is returned from a method or function with a nonnull return type or is passed to a parameter marked nonnull. The static analyzer checks for common misuses of Objective-C generics. The static analyzer checks for missing localizability. This check is off by default and can be enabled by selecting 'Yes' for 'Missing localizability' in the 'Static Analyzer - Generic Issues' build settings. There are 3 new settings related to these new features: CLANG_ANALYZER_NONNULL, CLANG_ANALYZER_OBJC_GENERICS and CLANG_ANALYZER_LOCALIZABILITY. CLANG_ANALYZER_NONNULL and CLANG_ANALYZER_OBJC_GENERICS Objective-C continues to get some love! Adding into the changes for nullability and generics, now the analyzer will start to warn you about usage not in line with your annotations. That's very good news, considering that the compiler checks were a bit lacking. Additional kudos because both settings are enabled by default. CLANG_ANALYZER_LOCALIZABILITY This is an intriguing one. Let's investigate further; Let's say you have some code where you set a string to a label: 1 label.text = @"not-localized"; You'll now get a nice analyzer warning: "User-facing text should use localized string macro" But you won't get a warning when the key is not localized. Like: 1 label.text = NSLocalizedString(@"not-localized", nil); Hey, we can't have everything, but here's my request for improvement submitted. Anyway, go ahead and enable these new settings! And use the analyzer! ## Transitioning iOS versions DevFeed: [Transitioning iOS versions]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-12-14T20:00:25Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [iOS](), [SDK](), [Mobile](), [Code](), [Operating system]() Tags: [apple](), [compatibility](), [deprecated](), [improvements](), [ios](), [mobile](), [sdk]() ### AI overview This article discusses how iOS developers can manage annual OS and SDK changes in long-running applications. It focuses on maintaining backward compatibility, supporting current and older iOS versions, handling deprecated APIs, and allocating engineering effort for transitions while continuing to deliver features. ### Source excerpt Having worked in companies developing their own products, I've faced many times the problem developers encounter when building iOS applications: Your biggest 3rd party dependency - the OS SDK - is changing under you every year. How does your team deal with this in a maintainable way? Long-term projects Unless you do consulting or freelancing, chances are that you will have to deal repeatedly with evolving code in the same project over the years. Even if you jump from project to project, chances are you land into existing projects where there's some code written some time ago. In longer projects software rot stays and the team needs to deal with it. A successful application will face this earlier than expected, and in the fast-paced market of mobile applications, every year Apple is renovating and ruthlessly changing the Operating System where our code lives. It requires non-trivial amount of work to keep up with changes, while still delivering improvements and features for our users. I've worked in teams where these questions were often raised: How do we keep modernising our code, while maintaining backwards compatibility for our users? What techniques can be use to keep moving fast, while still supporting older OS versions? How do we approach throwing away old code using deprecated APIs in a big codebase? How do we write new code taking into account that we will remove support of an older OS version? Fragmentation As I wrote before, developers in the Apple ecosystem face a different kind of fragmentation. We're forced to adopt breaking changes every year, or 'die' in the process. Apple forces us to start using new features of the OS, and has a policy of deprecating APIs a lot faster than we like. Instead of supporting a lot of older devices and operating systems, we face many breaking changes every year. A mobile engineering team should embrace change, knowing they'll need to assign some engineering resources to keep up with code changes required to support new and ## Building Swift on OSX DevFeed: [Building Swift on OSX]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-12-05T00:38:35Z Content type: tutorial Language: en Sources: [Miguel Quinones]() Topics: [Swift](), [Open Source](), [CMake](), [Compiler](), [Homebrew](), [toolchain](), [Xcode]() Tags: [build](), [build-system](), [cmake](), [dependencies](), [developer](), [getting-started](), [how-to](), [open-source](), [swift](), [xcode]() ### AI overview A tutorial on building the open-source Swift runtime, REPL, and compiler on macOS. It covers using a binary development snapshot or compiling from source with CMake, Ninja, and Homebrew, and explains that the resulting build artifacts are placed in a build folder. ### Source excerpt Swift is finally open source! This is great because of many reasons, namely the transparency and chances to learn from the people responsible of building the foundational language you work on. I've been checking how easy was to build the runtime, REPL and compiler, and it turns out the team made an excellent job to make the process very easy. Let's see how to do it. If you ever want to use a bleeding edge version of swift to build your application, now you can! Bear in mind that you should only use development versions of the compiler and runtime only when you are sure you need to do this. Generally as an application developer you rarely need to do so. But hey, let's dive in! The documentation is very good. Again the team has done an excellent job in my opinion, setting up a full open source setup for the years to come. So I encourage you to read at least the getting started and readme first. Downloading a binary development snapshot If you don't want to build from sources, you can grab the latest snapshot as described on the swift download page. It's certainly an option if for example you have an application written in Swift, and you want to assess how much things will change ahead of next Xcode release. You can check Erica Sadun's post if you want more details. Thanks Erica for sharing! Building from sources I just needed to install two dependencies on my machine, as stated in the repository: cmake and ninja. Be sure to set this up before starting a build. I'm using homebrew: 1 2 brew install cmake brew install ninja I chose to use ninja for the first time I would build Swift, as it is the default build system, and I wouldn't need to change configuration parameters for the build script. Once you've installed the dependencies, clone the required repositories. Bear in mind that the default build script will try to look for more than just the swift repository. As described in the swift README. So you'll need to clone several repos: 1 2 3 4 5 6 7 8 9 10 mkdir apple gi ## Three months with XVim DevFeed: [Three months with XVim]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-11-19T22:19:24Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Xcode](), [Vim](), [ide](), [Command-line interface](), [Learning]() Tags: [article](), [code](), [command-line](), [developers](), [ide](), [learning](), [navigation](), [refactoring](), [search](), [shortcuts](), [vim](), [xcode]() ### AI overview The article reflects on learning Vim and using XVim in Xcode to apply consistent keyboard-driven workflows. It discusses the time investment involved in becoming productive with an IDE and using command-line tools for navigation, search, refactoring, and editing. ### Source excerpt 'Know your key shortcuts' is the mantra of the productive programmer. I've chosen to try using the same keybindings everywhere, investing time and learning Vim. And using xvim in Xcode. In this article I'm going to try to explain why I did this, and I'll share my experience of the process. Knowing your IDE and being productive in it, is one of the best investments you can do as a programmer. We need to write code, and sometimes we do repetitive tasks if we are involved in bigger projects: Navigation and search, refactoring, some formatting and changing existing code. Vi(m) vi is a command-line text editor. Vim is an extended version of the same editor. The main difference from 'more modern' editors, is that it has two modes, and it's designed for proficiency in a kind of command language where the user specifies where he wants to navigate and what he wants to achieve. It was also designed to be completely controlled with the keyboard. Many people still use it nowadays, which is surprising given that it looks rather old-fashioned, and that the proliferation of different text editing modes has been massive. If you're interested but not familiar with the editor, you'll find that learning how to use it will be a significant time commitment. There's countless of sources of developers explaining why or why not they'd use such editor; you'll find them easily. The sources that inspired me and I go back to from time to time are: Why, by Jon Beltran de Heredia: Very old source but explanatory for somebody not familiar with the editor. Daniel Miessler's intro: Very well written examples and thinking mode that goes with the editor. Investments Getting familiar and productive with your IDE is a time investment. It can take you from weeks to years, and it's very recommended you do so, because it's rather useful to produce code with less time to have time for other interesting tasks (or coffee!). If you become fast enough, your thoughts will convert to code almost instantly, delay ## Jumping into existing codebases DevFeed: [Jumping into existing codebases]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-11-15T18:55:18Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Git](), [Code](), [Homebrew](), [HTML]() Tags: [articles](), [developers](), [git](), [history](), [make](), [time](), [visualization]() ### AI overview A developer shares a practical method for becoming productive in an existing codebase. The article recommends examining Git history and repository statistics, using git_stats and Gource to understand contributors, code changes, and project structure, and reviewing commit-message conventions. ### Source excerpt I've recently changed workplace - we're hiring! - and I've jumped into an existing codebase. This is a good time to review what I like to do when I start to work on a project in these circumstances. When you don't start a greenfield project, which is most of the time for many developers, you need to rapidly and effectively get to grasp with all the code, so you can become productive and acknowledgeable with any changes that need to be done. There's some things I always do in these cases. Examining the repository Git stats I always like to start with the repository itself. Looking at the history, commits and overall activity. Many times you will find that developers are not used to providing consistent and meaningful commit messages (how many times you've seem WIP feature X commit message?). So looking at the history is not informative. So I prefer to look at global statistics instead. Assuming you will work with a git repository, the first tool I like to use is git stats. As easy as: 1 2 3 gem install git_stats cd git_stats generate Running this tool will result in a nice html document giving insights about authors, commits, files and lines of code. It's mostly informative but it's good to get an overview of the key collaborators of a project, who created, and most importantly, who deleted the most lines of code! Gource A very interesting way to see the commit history in a graphical way is gource. I always like to run it for 5 minutes just to get a feel of the rush of the project, and basically to see in a glance what are the core parts of the codebase. It also is very funny to look at, and you can get a feel what is the core part of the repository, what parts changed the most, and the number of developers working at the same time. It's available via homebrew as well so very easy to install and run: 1 2 3 brew install gource cd gource Check the available options, like seconds-per-day, to customize how you see the animation. I like to run it with 2 seco ## Functional programming in the small, with Swift DevFeed: [Functional programming in the small, with Swift]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-09-09T15:00:23Z Content type: opinion Language: en Sources: [Miguel Quinones]() Topics: [Functional programming](), [Swift](), [iOS](), [Objective-C](), [Programming]() Tags: [beginner](), [functional-programming](), [ios](), [objective-c](), [swift](), [ui]() ### AI overview The article explains how iOS developers can apply functional programming incrementally in Swift. It recommends using functional techniques in small parts of an application while retaining object-oriented design for the larger structure, and discusses higher-order functions, closures, and trailing-closure syntax. ### Source excerpt In a previous post, I wrote about the choice of paradigms that Swift presents for it's target audience. I also gave my opinion on how people with different backgrounds might see and approach the Functional Programming paradigm. In this post I want to share how I started to take advantage of FP with Swift for the practical domain of iOS developers: Building apps. Silver bullets In software development there are no silver bullets to kill your problems and move on. We always need to find tradeoffs and evaluate our options to decide what would be the best choice. We often need to consider not only the technical aspects but cultural or team aspects too. iOS applications involve a great deal of UI programming. The iOS frameworks are object-oriented, and Swift is not a pure FP language. Throwing away all the code from Apple's frameworks just to make our code more functional is not a realistic approach. Thus we need to balance where we want to use from different programming paradigms. For a beginner, or a team with not too much experience with FP, my choice would be doing Functional Programming in the small, Object Oriented in the large. FP in the small using Swift Let's look at the features of Swift and the standard library that help write more 'functional' without having to restructure or change how we build a project. Better functions One of the first terms you will hear when diving into FP is that functions are first-class citizens, or the language supports higher-order functions. What this means is that functions are treated like any other type. Think as functions being treated like objects; They can accept other functions as input, return other functions, and be stored and passed around. Under this definition Objective-C kind of supports this, but it's lacking in several areas. Firstly, there's a difference between blocks and selectors, the way to use them is different and the syntax is more complex. Secondly, in Swift a closure is a function without name, and they bo ## Poor man's functional programming DevFeed: [Poor man's functional programming]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-08-31T20:00:00Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Functional programming](), [Swift](), [Mobile](), [Object-oriented programming (OOP)](), [Programming]() Tags: [beginner](), [functional-programming](), [ios](), [learning](), [mobile](), [oop](), [programming](), [swift]() ### AI overview The article encourages iOS and Mac developers familiar with object-oriented programming to explore functional programming through Swift. It discusses the learning barriers, abstract terminology, and gap between toy examples and large projects, while arguing against treating programming paradigms as ideological camps. ### Source excerpt It's a very exciting time to be an iOS or Mac developer. The platform moves very fast and we got a new toy (language) to play with: Swift. It's the perfect time to reevaluate, learn and evolve as a programmer, because you will be forced to adopt this new language (yes, I think Swift is the future, 100%). I want to relate this to the fact that most iOS engineers, or mobile application developers, are traditionally familiar with Object Oriented Programming paradigm. But Swift offers more than different syntax and OOP. I'm referring to some features inspired by functional languages. If you've ever had an interest, but never the chance or motivation to go forth and look into this paradigm, now it's the perfect time to do it. Functional programming is... I don't want to start reviewing what functional programming is, there are excellent resources out there, check them out. I want to point out how a beginner, somebody who starts learning Functional Programming (FP), might feel: Too abstract Not applicable to my problems For academics What does even 'pure' mean? I need to mutate stuff! Meh, I'll go back to my familiar way of doing things There's a higher barrier of entry to learn how to think and code programs which are more 'functional'. The concepts are abstract, and the benefits are often described as it's more functional without emphasis of what you are actually gaining. Also there's the problem that many times all is explained by simple examples. But every programmer knows there's a huge difference between toy programs and real big projects. Flame wars You'll find engineers and computer scientists that believe that the only and true way of doing things is of course thinking functionally, and we've all been doing it wrong during the last decades. The math is the only source of truth and validity, hence FP is the only way. They've got their very valid reasons to think this way, but my opinion is that many people familiar with FP start to use higher-level vocabulary, and d ## Freehand Drawing DevFeed: [Freehand Drawing]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-08-20T20:09:40Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [iOS](), [coding](), [Refactoring]() Tags: [article](), [blog](), [coding](), [ios](), [refactoring](), [technical](), [tutorials]() ### AI overview The article reflects on a three-part tutorial series about building freehand drawing for iOS. The series covers a basic implementation, undo functionality with refactoring, and smoother strokes. It also discusses the challenges and rewards of writing technical tutorials. ### Source excerpt Yesterday my last post on the series 'Let's build Freehand Drawing for iOS' has been published at Badoo Tech blog. It's been a very good experience for me, and of course I recommend you visit the tutorials if you are interested. I divided the tutorials in 3 parts: Part 1: Introduces the feature and a naive implementation Part 2: Adds undo functionality, refactoring along the way Part 3: Improves stroke to make it look smoother Building tutorials is hard This series has been my first take on writing technical tutorials. And I must say that it's a lot harder than I thought. You need to keep track of the content, code correctness, and the pace of the articles so it's readable and understandable. Coding while writing an article is challenging, but the experience has been very gratifying. I also get to brag about something I was really happy to build for the Bumble project. So I think I'll definitely write other tutorials in the future. ## One commit a day DevFeed: [One commit a day]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2015-08-07T20:22:22Z Content type: article Language: en Sources: [Miguel Quinones]() Topics: [Programming](), [App]() Tags: [app](), [coding](), [programming](), [side-projects]() ### AI overview The article recommends making daily progress on long-term side projects, even if only for 20 minutes. Maintaining a regular rhythm helps preserve motivation, focus, and momentum toward completion. ### Source excerpt One commit a day. A lesson I've learned the hard way when dealing with long-term side projects. The first push You are starting a new side project. That new library, framework, cool app idea or just a hack you had in your mind for long time. Starting it is easy, as you find some spare time and kick off your editor of choice and start writing code. I've done this some times, but then if having a full time job, keeping with your side project is very very hard. But to successfully build something useful, something more than a proof of concept, you will need more than just one evening. Keeping up It's after some evenings working at home that I would say: "Today I will rest, I'm not working on my side project". And this act will make that the next day I will be thinking again that I can rest another day. And rest I will. The long streak of commits, progress and closeness to completion stops right there. It will be very hard for me to restart my work again. Stopping for one day made it harder to restart my work and delayed the whole project for more than a week. I've heard many people have this problem and the solution is very pragmatic: A commit a day. A commit a day When you work on a side project you do it because you want to use your spare time to build something. It's a project nonetheless so you still need some goals and motivation. I've found that stopping the regular work can kill your motivation and focus. So I've proposed myself whenever I work on a side project, I need to advance something every day. I'm building an app now (shh, top secret), so I will work on anything related to it at least 20 minutes every day. It does not have to be programming. It can be updating a design, thinking of new features to add in the future, tweaking landing page, or actually coding. This act of keeping up with your project makes it so that I will focus more on it, and I will not loose the sense of progression. Also if I will work on the project only during weekends I found that