Today I made an exciting discovery: the existence of AnchoredRelativeFormatStyle. An API that, as of the time of writing this, barely appears in search results other than Apple’s sparse documentation. And to my surprise, it’s exactly what I’ve been looking for over the past few years.
Recently, while watching a Tsoding stream, I saw something that piqued my curiosity. Alexey demonstrated how one of his applications could render a video just by calling into the ffmpeg binary directly, instead of using it as a source code dependency or even a static or dynamic library linked to his program.
Sometimes in command line tools we want to perform some cleanup final task before the process is killed. To detect this scenario we can hook to unix signals like an interrupt and perform the needed work before existing from the process.
Recently, I finished an almost final draft of my novel and decided it was time to refresh my online presence and website. Instead of starting my next novel, I dove into creating the next version of my site, what I call alejandromp4. And, of course, you know what that means… using a new static site generator! Yes, I have a problem with focusing my hobbies; I’m working on it.
In my team, one of the things we always make sure of is keeping our dependencies up to date. We rarely add a dependency without a really good reason, and when we do, we assign an owner who is responsible for keeping it up to date.
Every year SwiftUI improves and gets new modifiers that widen the capabilities of the framework. Sadly, as responsible developers, we can’t use any of that because our users take some time to update and, as opposed to the Android ecosystem where Jetpack Compose is just a library embedded in every app, we need to wait for our users to be at the required minimum OS version to enjoy those fancy new tools.
It’s been a while since the last time I thought about traits and mixins in Swift, but the WWDC23 presentations about macros brought a lot of memories from those times when I really lamented not having that functionality in the language. Thankfully, Swift 5.9 gives us a form or meta-programming that allows us to get some basic support for mixins.
One of the many things I love about working with The Composable Architecture is how it encourages the developer to focus on domain modeling. I think that properly designing the models or entities of a domain is one of the biggest contributors into good code, and the lack of it makes everything way harder than it should be. Thankfully Swift is a great language that allows us to express almost everything we need to in a very strict and concise way, another reason the language of your choice matters most than people pretends.
Buckle up. This is an adventurer journal while exploring what’s the best way of exposing the new style of formatting APIs in Foundation. We will walk through the paths of the type system, including existential types, generics and type erasure; and discover the magical possibilities of the dependency system.
The folks at Point-Free have given us yet again a new tool to improve our Swift development: swift-dependencies, see their announcement. Let me show the journey I’ve been for the past couple of hours with excitement and discoveries with this new library.
I’ve been very excited about memory ownership improvements to come to Swift, and now that they seem to materialize, I needed to share it with you. Specially because I feel this topic is very complex in people’s mind, and many will discard it as something only useful for experts, advanced uses or even “for nobody, Swift is getting too complex”.
One of the nice things about Swift Concurrency is its cooperative thread pool. When writting concurrent code you should not think about threads but is still good to know how things work under the hood.
Now that I have this site building on Netlify I wanted to start writing more far away from my computer. Of course I immediatly found a bit more friction that I had to solve.
With the whole move to Mastodon, I’ve been thinking a lot about owning my content again and what will happen with all the interesting things I’ve written on Twitter. That’s a topic that is worth its own post, but it got me thinking about focusing more on this blog again.
Today I spent a couple of hours understanding how SwiftUIaspectRatio modifiers works and how it interacts with Image. It’s a surprisingly simple system, but also one that made me wonder why things worked the way they worked.
In the early days of Swift, one thing I really enjoyed was the focus on properties (bye-bye ivars!) and the unification of stored and computed property syntax. It became very common to define properties that initialized some parts of your view automatically.
Swift’s Optional type is one of the biggest hits of the language. Mainly because it’s opt-in. Everything is non-optional by default, which solves the old problem of having to deal with nulls everywhere. That said, nulls (or Optional.none) still shows up a decent amount of times, so the second thing Swift did very well was to provide great affordances to work with optional at the language level.
Sometimes some topic gets in my head and doesn’t leave until I’ve gone far enough to satisfy my curiosity. Usually this ends up with me spending days writing some code that just goes to the trash once I’m done with it, but today I decided to share a bit of one of these rabbit holes I went down to.
Following Structured Concurrency was one of the best decisions Swift could have made when introducing concurrency into the language. The impact of that decision on all the code written with concurrency in mind can’t be underestimated.
One of the beautiful things about Pointfree’s Composable Architecture is how you can start using it on a smaller part of your app. It makes it very easy to improve a codebase without having to stop the press, which is something that I always require of any new technology.
Today I want to show you a rather obscure feature of Swift. You will learn a bit about Swift’s type system, type inference and other nice powers that the language has.
Today I want to share a weekend experiment where I built the classic Matrix effect in SwiftUI. It all started after seeing this tweet of the effect implemented in Compose. I immediately wondered what would it take me to build that in SwiftUI, so when I had some spare time in a weekend I gave it a go.
One of the most important aspects to understand about Swift Concurrency is how cancellation of async tasks works. You may expect that when a task is cancelled, it immediately stops, like when you kill a process. But that’s not at all how it works, cancellation in Swift is cooperative.
WWDC21 has brought many cool things and there is one that will facilitate a lot the creation of new projects with dependencies. Until now it was a bit of a pain to remember which packages you wanted to add on almost every new project. It was such an inconvenience that I even have my small CLI to create new Swift packages. But I think now there is a better way!
As last year I decided to share my unedited notes from the sessions I’m watching. The difference is that this time I’ve focued more on the topics and not on the sessions themselves. I’ve found this way more approachable this time.
And here we are again! A new year, a new WWDC! I’m writting this after the first day of video sessions so there is still a bunch of cool things to unpack, but I think is alraedy a good point to sit down a bit and reflect.
We’re just in the week of WWDC and it’s clear that Swift’s Concurrency it’s the biggest topic that will change how we develop. I’ve been following its evolution for months now and I’m happy to see how Apple talks about it on their sessions, it helps us see how much they really believe in this new langauge feature.
Swift is about to get its Concurrency features. Their development is going very well, with many proposals actively reviewed and a lot of the work already available in recent snapshots. The story is big and with many moving pieces interlinked with each other. That makes it a bit hard to wrap your head around the entire thing. Specially for those that don’t read Swift Evolution as a hobby ^^.
SwiftUI’s layout system is very nice to get started with. Combining stacks and modifiers you can get very far very quickly, but at some point you will need to pass information up the view hierarchy. Thankfully SwiftUI has a solution for that: preferences.
Swift is well known for its lean syntax that helps newcomers understand the code relatively quickly. But it’s also a language with advanced and powerful features. Sometimes this makes part of the community wonder if it is going too far. In this post, I’m glad to merge these two worlds and use an “advanced” feature of the language to improve the base syntax. Of course I’m talking about Result Builders and a DSL for Dictionary literals.
When Apple released its own SwiftUI tutorial I decided to give it a try. This was not a simple tutorial introducing the basics of SwiftUI, but a more overarching training to know how to create a real application in SwiftUI. From custom UI to sharing data between and interacting with frameworks.
I’ve been a big fan of what Apollo is doing for a while, and recently they have been doing various interesting talks and interviews. In this post I want to review and share my notes about the conversation that happened on February 24th 2021 around GraphQL modeling and backend driven UI.
In this post I want to show you a little behind the curtain. As you may have noticed if you follow me on Twitter, recently the tweets with links to this post got a little fancier. What you may not know is that these images are generated using SwiftUI.
One of the major benefits of SwiftUI is its amazing DSL. A feature that not only makes it nice to read but also makes it possible to use the type system to unlock tremendous performance benefits. AnyView is a view that defies all of this, and although useful in very specific circumstances, you should always try to use a better alternative.
SwiftUI is an amazing tool to create all sorts of views in our applications. But many times we want that ease of use to generate graphics that can be used outside of apps, usually as simple image files. That’s why is so useful to know how to generate images from SwiftUI views. This power unlocks a new world of possibilities!
Having a good process to update your tools is very important, specially for those that affect directly your code. I’ve talked about how I update swiftformat and this post will discuss my update process for SwiftLint.
Talking about how one updates a tool may seem a bit nonsensical, after all, what dificutlies can you have when updating a tool? Well, you would be surprised! But no, this post is not about issues when updating swiftformat. Quite the opposite!
Legends of Runeterra has become one of my favourite games. I started playing it since the beta was available and haven’t stopped since. It caught me by surprise, but it’s been one of the few games that I’ve played for so long. It was just a question of time that I found some little project to mix the passion for this game with the passion for coding.
Optional equitability is one of those aspects of Swift that seems simple at a first glance but that makes you stop and think twice when you encounter it in actual code. The good thing is that once you pause and look at it you realise is trivial.
Sometimes when writing Swift code you want to reference an instance before its creation. It’s not a very common, which is why I’m writing this post so I can easily remember it next time it happens.
This post is a personal opinionated piece around unit testing and the dogmas of our industry. Be sure to come here with an open mind and respectul toughts. I will also link to some Pointfree content so make sure you check them out.
My birthday is the middle of July, seven days from now, which has always made me consider summer as the division between years. That mentality was reaffirmed when as a teenager I got hooked up on TV Shows. Those shows are broken down in seasons, and usually summer was that weird space between seasons without much interesting content to watch.
iOS offers the ability for applications to add quick actions to the home screen icons. Implementing this feature often requires things that are not easy to access in most common App architectures. In this post I want to show you how The Composable Architecture makes it very easy to implement without sacrificing your code.
After having absorbed the keynote and SotU the wait for the sessions started. But with patience, and thanks to the constant flow of time, California o’clock arrived and, after a little delay, we got the first batch of WWDC20 sessions!
WWDC Monday finished! And what an evening! For the first time I was able to stay awake to watch the SotU live and it was great ^^ The problem is how then I spend a couple of hours playing with SwiftUI and time flew by.
The introduction of SwiftUI and previews changed completely my process of developing applications. Having such an easy way of quickly prototyping UI ideas affected the rest of my process. But as much as I love Xcode previews, they are not perfect. In this post I want to share with you a small trick that can improve a lot your iteration cycles.
It’s that time of the year again! WWDC 2020 is around the corner. As every year around this time I start thinking about my wishes for this version of WWDC and solidifying them in words.
Swift type system is quite powerful and the where clause is a very important part of how developers interface with it. This keyword allows developers to constraint code to a set of conditions. Swift 5.3 frees this keyword to be used in more contexts.
Swift 5.3 comes with a nice addition for enums: it will synthesize the required implementation to conform to the Comparable protocol. This reduces a lot the boilerplate needed to make your enums comparable.
PointFreehas released a library with their Composable Architecture and I’ve been showing it a little bit on livestreams and videos. This page wants to serve as an index and a summary for this content.
Protocol extensions are one of the most powerful features in Swift, but they also come with a bit of danger. In this post I will explore how this feature interacts with class inheritance and how dangerous it can be.
Welcome to alejandromp3. As you may have noticed this website has a totally new design! Not only that, but is now using a different static site generator purely in Swift!
I’ve been using FLEX for years and I just realised the little I’ve done to promote this great tool among the iOS community. So here is my attempt at giving some love to the project and show you the superpowers you can get with it.
Publish’s Foundation theme is a very nice starter, but at some point you will want to accommodate it to your needs. When you start touching the CSS you will quickly notice that the workflow is far from ideal.
While developing the new version of my website with Publish I had the necessity of have live reloading of the page while developing. I’m happy with the solution I’ve found even if it’s not perfect.
In the past I’ve written about the setup I typically use with Danger. It worked quite well given the limitations but there was always the annoying restriction that to update the checks you had to push a commit so the CI could run Danger again.
I shared a very special video on my Following Swift Evolution video series the other day, Road to Swift 6! I think it’s an important moment to look at what the future of our beloved language looks like so I spend some time cleaning up a transcript of the video to have it posted in this blog, for posterity.
With the release Xcode 11 is now easier than ever before to work with the Swift Package manager. If I enjoyed making CLI tools with Swift before, now it’s a pleasure! Lately I’ve been working on a small plugin for the recently released static site generator Publish. And the plugin is itself a Swift Package so I had to opportunity to enjoy SPM and Swift tooling development.
One of the common things we want to display with SwiftUI are lists of our models. The basics of it are pretty easy, you just need to use a ForEach view.
This week I removed a big chunk of code from our app, an entire section/feature. I’ve been working on this codebase for years and I had the opportunity to do a bunch of cleanups. Thanks to that I’ve organically developed a strategy to remove code that is quite successful to me.
SwiftUI has some presentation modifiers to display alerts, sheets and full screen views. On one hand, presenting an alert is nice and easy, it feels really well designed. But on the other hand presenting a modal screen (or action sheets or popovers) is too cumbersome.
In my previous post about SwiftUI buttons I described a technique to reuse button configuration with a ViewModifier. Now that beta 2 is out, we finally have the proper tools to reuse styles in a much better way!
Yesterday I shared with you a post where I was trying to understand SwiftUI’s layout system in order to implement equally spaced distribution for views inside stacks.
The abstractions on SwiftUI are so composable that customising the UI it’s basically an intrinsic property of the framework. Let’s take a quick look at some things you can do with Button.
WWDC’19 has been great and I’m obviously hyper excited about SwiftUI but if there is one thing that I like more than watching a great announcement is watching great video content, and the WWDC sessions are the best!
After all the game changing announcements on the WWDC one of the words that is used a lot is “finally!”. We’re excited and happy that Apple as finally given us a new UI framework, FRP, etc. But it’s interesting how the way we all talk implies that Apple has been ignoring us for years and until they woke up in 2019.
WWDC ’19 is over, and what a week! Let me start by saying that this is probably the best WWDC ever. We have seen the announcement of game changing technologies for the Apple developer community, but even ignoring those big announcements, the rest of smaller details make on itself a great WWDC.
After writing about my perfect notes app and comparing the available options I decided to move to Bear. My tasks from Todoist were one of the first things that I moved, and with that change I immediately noticed that in some occasions I really needed a quick way of seeing my tasks.
I’m so thankful to have people like Jonathan Blow that is able to challenge the status quo of our industry. Software quality is decaying and we’re part of the problem. If you still think that caring about this things is a waste of time watch this talk, it may help you open your eyes.
Today I’ve used Protocols to make a generic function only accept a certain number of types. The interesting part is that the only thing the protocol has is an associatedtype, there are no other requirements, which may seem a little weird at first.
After finalising the InterpolableLanguage protocol in the third part of this series we will finally put it to good use and show an example of this can be used on day to day code.
In the first article of this series we made a safe string type that was safe to use but with a cumbersome API, and on the second article we made that API much nicer to Swift 5 interpolation. On this post we will generalise that conformance to make it easy to create new safe languages.
In the previous article we made a safe string type that was safe to use but with a cumbersome API. In this part we will use new Swift 5 interpolation system to make it really nice to use.
The String problem is something that I’ve explored before, in my 2015 post Solving the Strings Problem in Swift. The solution back then was far from ideal as Swift was missing a powerful String interpolation system.
This is a small trick that I use when I’m writing a script in Swift that performs some operation in a large number of objects, usually files. More often than not this operation is somehow destructive and ends up overwriting the original file, so I want to make sure that I got the changes right before applying it to the entire set of data.
After a long day of hard work I endup having many apps open. Xcode, Visual Studio Code, Simulators, the terminal… when it’s six o’clock I want to close everything work related instantaneously whiteout effort.
At the iOS team at Lifeworks we’ve been using Danger since its inception. We care about the etiquette of our PRs and the more that can be automated the better.
Last week I participated in the first Blackthornprod GAME JAM. I had so much fun creating a small game involving some mechanics that I wanted to explore for a while.
Everyone knows that NSSpain is one of my favourite conferences but sadly this year I haven’t been able to assist. Luckily for me the recordings are already up so I watched the talks online ^^
I haven’t been doing much maintenance to this website since I migrated to GatsbyJS, but recently Gatsby has announced its 2nd major release. This is a big step forward for this amazing static site generator and I didn’t want to wait much to use it’s cool new capabilities.
One of the best things of modern Swift is the introduction of KeyPath. It allows us to reference getters and setters as first class values in our code. With them you can simplify a bunch of code and make it less error prone. In this post I’m gonna evolve the groupBy function from GroupBy in Swift 2.0 to use this new functionality.
On 2014 I wrote a post about how to drive a UISegmentedControl with the new powerful Swift enums. Back then the major complain was that to get all the cases of the enum you had manually list the cases of the enum, which was tiresome and error prone.
One small inconvenience of a static blog generator running without a CMS is that to create a new post in markdown you need to add manually the front matter in the top of the file. That’s why the first thing you should do after setting up your static site generator is to create a small script that automates the new post creation.
Server side development and the managing of the infrastructure has gone a long way in the recent years. From scalable virtual machines easy to manage to containerisation with Docker and even serverless functions with Amazon Lambda. But all of this advancements still require you to change your mindset, from programming your application to configuring the infrastructure.
After the setup of this new website with Netlify I lost a little the perception of when the website was up to date. Before I had to run the build and deployment manually from my console so I knew exactly when it finished, but now thanks to having automatic deployments on every commit I’m not longer sure about it.
I was reading the Rust forums when I saw this post talking about an oficial Rust error crate. It reminded me about the discussions in the Swift forums about making a bigger standard library.
On every new iteration of my website I’m always happy to have taken the decision of using a static site generator instead of a big and fat CMS. This gives me the freedom to change the hosting easily and now I’m taking the opportunity to move to Netlify.
As I mentioned in my previous post, I’m Rebuilding my website with GatsbyJS. At the moment of writing this the migration is pretty much done. I spend the morning setting up a temporary domain, nginx and Digital Ocean to see how it would look and behave when deployed. There are still some things to improve but I think is a good time to pause and see how the experience has been.
As every year after WWDC is time to sit down and watch the videos of the sessions! I wrote last year about How I watch the WWDC videos and this year I’m doing a similar thing. I still use the unofficial WWDC for macOS to download the videos and watch them at more than 2x in VLC. This time I decided to use a single note in Notes app to keep my notes of the sessions and to mark the videos I’ve seen. And because everything is in a single note it makes it really easy to share, so I decided to share my notes with you!
One thing that I always want to do is talk about WWDC before and after it happens. I used to do it when my podcast was active but without it I didn’t find the place or the time to give my opinions.
This past week Google did their annual developers conference. I rarely watch the main keynote because I’m not that interested in their products but nonetheless I always keep an eye on what other platforms are doing, there is so much to learn from others. This year they announced Android Jetpack and more Architecture components, I think is good for the Apple community to take a look at how Google is treating their developers and learn from it.
Make is one of those tools that I’ve always been curious about but never had a good change to try it until a couple of years ago. It is a really powerful and convenient tool and in all honesty I just use it as a task runner, I define some names for a set of commands and run them that way.
RxTesting makes testing a custom Rx operator an enjoyable experience. Being able to fake time simplifies a lot the develpemnt of reactive code and helps on building confidence in the code.
How flatMapLatest cancels an API request? This is a common question that people has when they start learning about Rx. Specially since RxSwift has an example of this in the README.
p5.js and the rest of Processing projects are an amazing way of making coding more accessible to everyone, allowing creative people to make interactive applications with ease and teachers to introduce kids to programming in a entertaining way.
Today I was reading Composing types in Swift which showcases the different ways of composing the different types in Swift: structs, classes and enums. Is a good read, specially if you are too deep in the OOP mindset.
While programming with a static type system there are times when you write the definition of a function but you still don’t have any idea on how to implement it.
This post is just a dump of the things that came to mind while watching Jonathan Blow’s libraries discussion. I’m not an expert on any of this but I find it so fascinating that my mind can stop thinking and taking notes when watching Jon streams.
Swift forums are live! This is a great change that many of us have been waiting for a long time and that marks a new era for the Swift community. I would like to take this moment to reflect on the state of Swift and express some of my wishes for 2018.
I recently discovered the podcast LambdaCast, a really interesting podcast about functional programming with hosts that are at different points on the path to functional programming. This gives an interesting view to the listener that can get explanations from starters and experts. They usually talk about FP in terms of how to use them in imperative land, mainly with Javascript and C#. That’s nice for many people, but every time they give an example my brain starts thinking about how Swift deals with it.
I discovered the Advent of Code from some retweet on the first days of December. I found them really interesting and original so I decided to give them a try. I know, they’re just programming exercises but they’re written in a nice story driven way!
In this post I’m gonna explore the talk Idiomatic Kotlin by Dimitry Jemerov. I’m gonna do it by showing how each of the topics the author talks about could be done in Swift.
One of the best things about developing for iOS is having the power of the amazing frameworks that the Apple platforms have. Foundation is easily one of the best platform frameworks out there and in this post I want to show you how to use a gem that not a lot of people is aware of.
I’ve been always a big fan of productivity, time is gold. But funny enough, as many other people, we fall into the traps of being productive by just spending more time on looking for tools and solutions to be more productive. This is not a bad thing per se, but it can end up being. You may end up having a false sense of productivity because you improve your workflows and tools. But, in reality, the only thing that matters is the output of your work and, specially, your happiness.
Some days ago I finally merged one of the biggest Pull Request our team has seen, the migration of our codebase to Swift 3. I decided to write some words here as a way of remembering the beginings of the language we expect to work with for ages.
The chapter 5 of Crafting Interpreters has been published and after a first read I started writing some Swift code to continue my implementation of the interpreter. Here there are some thoughts that I’ve captured while implementing the Expression classes.
One of the things I think is really important in any team is to keep track of the performance. Not to use it as ammo to blame individuals but to learn and have data to keep improving.
Yesterday I gave a talk about Functional Reactive Programming to my coworkers at LifeWorks. At first, I wanted to give some insight about it to the Android team, as they were using Rx for the API layer. But at the end there were more assistants than I expected. From Android and my iOS team to Web and backend developers. So I had to do the talk as generic as posible (although the code is in Swift) and also try to convince everyone about how this is the next step.
I’ve always been a big fan of Linked Lists. Maybe is because it was one of the first data structures that I learn how to implement and they were my introduction to the fascinating world of pointers. Nowadays I hardly think about pointers in my daily work. In Objective-C you just treat them as the objects you want to message with, and in Swift the lovely * has disappeared. But I still feel nostalgic sometimes.
The post Mock yourself, not your tests immediately captured my attention just by saying “I feel like we abuse of them”. As I’ve been having more and more the same feelings about mocks in my tests.
Without entering in the dicussion about MVVM I just wanted to quote here an interesting paragraph of the linked post. It’s mainly for my own memories, as it’s something related to a topic that I’ve had in my mind for a while and I want to have this words saved somewhere that I can refer back when I’m lost in the forest of Patterns.
It’s a known fact that in our community there are always a constant discussions about the best patterns to use when building an App. But I find the discussions about MVC, MVVM, Viper, MVP or whatever new fancy word somebody has come up with today become, at some point, kind of useless. At the end, all of them are quite similar, and all of them are good for some situations and bad for others. If you base your software architecture in separation of concerns you can give it the name that you want.
Facebook has brought to the open source world a bunch of amazing technologies, React being one of the more widespread ones. It is really interesting how old ways of doing UIs like the immediate GUI mode has come back with a more functional and descriptive twist. But for me one of the key and most amazing technologies is GraphQL.
One of the things that Apple released on WWDC was the official support for Xcode plugins. Although in a very limited way, is really nice to see Apple opening Xcode with an official framework.
One of the most interesting parts of software is decoupling. Although not the kind of decoupling that we are all used to in our code, but the kind that decouples parts of a system from itself at execution level, a dream where software can talk with each other. Sadly that is not really extended nowadays at an application level, so any little piece of software that tries to do something like that calls my attention.
Being able to conform to a protocol and automatically have the implementation that you need is really a game changer. Having trait like functionality is one of the most interesting aspects that Swift has given us.
I’m always interested in knowing what is going on in other communities, it helps me a lot to understand how others work and what tools they use. Anyone that knows me knows that I’m not a big fan of Javascript, but nobody can’t deny that web development has some tools that would blow the mind of any native devs.
The other day, while I was writing a Swift script, I added an option to make it run continuosly so it could be on a server doing its job without stoping. for eva.
This is the second part of my posts about the sate of scripting with Swift. In the previous post I wrote about what I expect from a language toolset when writing scripts and where Swift still needs some improvements. In this post I want to do a quick overview of the libraries that I used to write the script.
In the past few days I’ve spend some time writing a little script in Swift and I thought it was a good time to revisit the state of the Swift ecosystem as a scripting language.
Getting C-level performance in Swift for numerical algorithms is quirky but not particularly difficult. If you limit yourself to value types (no classes or existentials), use unsafe pointers and tuples instead of arrays, use overflow discarding operators &+/&-/&* instead of normal +/-/*, use while or repeat/while for your loops, then Swift and clang C will generally compile to identical instructions.
Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself?
I really liked this post about Misused mobile UX patterns. I’m not a UX or UI designer, but after all this time being a user and a developer I feel I sometimes have a reason to defend some behaviors. But still I have to shut up and implement things that are not the best experience, because general UX fashions says it or because business doesn’t want to compromise. And let’s not forget that sometimes is also because developers are too lazy.
“Teaching C” is really nice write up on what to teach in a C class. It has been a while since I was a student in University but there are some important points that I would have loved to know at that time. I think C is a much better language that people usually says, but the shortcomings make it have really bad publicity. If teachers can do a good job when teaching newcomers maybe we would not be creating software with such a poor performance and quality, and accepting it as a normal thing.
Really interesting post about MIR. I really like this kind of posts that the Rust team publishes giving insight into the compiler internals and decisions.
The other day I had to work with some date formatting on iOS and Android and I end up using the great https://nsdateformatter.com website. I immediately missed the option to change the locale and seeing that it was open source I took my chance to contribute.
A while ago I wondered how easy would be to make a screenshot of a window in OS X from another application using some system API. With that idea in mind last Christmas I started a project that ended up being too time consuming.
A couple of months ago I wrote a small prototype of the well known Conway’s Game of Life. This kind of simulation has always fascinated me. Giving a set of rules and an initial state to the computer and let maths (and life) do its job has something special.
I was reading about Error Handling in Rust to have a better understanding of the implications of typed throws in Swift (thanks to David for the proposal). At the end of that guide there is an example using a simple script to search for the population of a city in a CSV. This are my conclusions after porting that script to Swift.
We are used to treat closures as first class citizens in our code. Same goes to functions as they are interchangeable. But we often don’t think of them as actual types. So they also can play with the rules and abstractions that we usually attach to classes or structs.
Since Swift was open sourced I’ve ben scanning trough the mailing lists and there has been some interesting proposals for the future of the language. There are other places were people summarizes the conversation, but I just wanted to write here the proposals that are the most interest to me.
I’ve been following the linked blog because I’m really interested in the usage of Swift in environments different from the typical Apps. And because using it for robotics seems pretty cool.
Today I had to do a little research on the state of JSON mappers in Swift for a new project. I’ve been using a simple JSON library to help me deal with the JSON structure in a safe way, but for this project I had to use something a little more sophisticated like a mapper.
I absolutely recommend you to go and read the linked article. This posts by the Artsy devs are so great for me since I’ve been following closely the development of their Apps since they are open source. And by closely I mean really closely, believe me.
developers have become complacent in being wasteful for the benefit of their own development ease instead of considerate of the time and resources they are taking from customers.
The author of the linked post gives some reasons on why Swift is a good language for an introduction to computer science class. I’m really interested in Swift being a good language to teach and I found the post really interesting.
This post is one of those ones that I’ve been wanting to write for a while. It was some days ago when, by coincidence, I was reading a post about dependency injection at the same time that a coworker came to talk with me about the topic.
Protocols in Swift are really powerful thanks to be able to be generic and to protocol extensions. But there is some things that drive us nuts. Mainly the usage of generic protocols in collections.
The other day while I was adding the ability to generate the protocol file to my Sketch plugin I took the opportunity to make a couple of changes to the code.
Last week I had to made some changes on the colors of the WorkAngel app. The colors of that app are retrieved through an object called ThemeColor (we have another for the fonts). That object is the concrete implementation of a Theme protocol that defines the names of all the different colors that the app needs.
I’ve been reading and talking with people that when explaining functions like map, filter or reduce they start with “it loops over the collection and…”. When I ear that my mind starts thinking in why people doesn’t care about the concepts behind things.
I’ve been lucky to have the opportunity to work in a bunch of different projects in my years as a developer. In all those projects I also had the opportunity to work with a bunch of different designers. I may be a good developer but to create a good product a good designer is absolutely needed. I think people has different kind of minds, and you need different minds to create a great product.
I would like to talk about a video of a great talk that I really recommend. I’m really interested on the topic of sharing code between iOS and Mac because basically is what I do with BingWallpapers.
As I said on my Fist impressions on WWDC 2015 I was really excited for finally having traits in Swift, in form of Protocol extensions. After playing with them this days I most than happy :) But I’ve seen some people struggling to understand how the dispatching of the methods works, in other words, which method will be called?
I mentioned the new Swift error handling in my WWDC first impressions post. And although it’s true that I still have not had the opportunity to use it in a real project I’ve been playing with it in playgrounds :P
Every year, after the WWDC I usually record a podcast episode talking about my feelings of the keynote. This year I’ve been keeping a list of the things that I like the most, so I will leave it here as a reminder to myself.
Today I’ve been updating BingWallpapers to use the last version of Swift and also include the latest changes of WallpapersKit, the framework that is shared across the Mac and iOS versions.
Today I found this great post by Zach Holman. He presents some points that can contribute to make you a better developer. I was reading it with attention cause I always liked how Zach explains things and then I read this part:
Yes, the title is not wrong. Apple just released Xcode 6.3 beta that includes multiple hugeimprovements to Swift 1.2 solving a lot of concerns that we all had. But the cool part is that indirectly Objective-C also has improved.
Lately I’ve been working on move my site, again, to Jekyll. Using directly the original Jekyll and keeping my customizations apart from the source I think that I accomplished what I wanted and at the same time I don’t will not have much problem to keep up with updates.
This weekend I wrote a little script that helped me to connect two of the main things that I do everyday: save things into the Safari Reading List and watch Youtube videos offline.
In the previous post I talked how to connect Minecraft and the Real World. In that case I made my real lamps follow open at the same time as my in-game lamps.
For those who don’t know me I have to say that I’m a big fan of Minecraft (1 and 2). And I’ve always wanted to connect the things that happen in that virtual world with the things in our real world (and other people have done great things; House light sync, controlling a Christmas tree. Now that I have one of the pieces of the puzzle I am available to do it, so this morning I started writing some code and in a couple of hours I accomplished my objective.
The other day I was talking about games with my friend Marc and we ended up talking about Don’t Starve, an amazing game. He confess me a little frustration about the fire camps, he never knows how much fuel they have left. The conversation ended there but the day after I came up with a simple mod that helps with just that.
I’ve always been fascinated by the culture behind dotfiles, those files that people have automated to be installed on a new computer to have everything set up just the way they want. Configuration for development programs, terminal settings, aliases, colors… But the truth is that I’ve only seen all of this from afar. I was very interested, but all these kinds of things come from necessity, and I’ve never had this necessity—until now.
By default a Swift playground stops it’s execution when the top level function finishes. If you want to run async code you will never see the results. The system doesn’t provides a waiting architecture like node.js, which is a bad thing scripts.
For now, the Siwft and Objective-C protocols are two diferent things. The biggest differences is that Swift protocols can have structs and enums and can be adopted by value types.
Today I released AMPActivityIndicator. I wrote this little class a year ago and today I made a little clean up and made it available through Cocoapods.
A good bug report is one that describes the problem well enough that someone familiar with the project can understand and act on that bug report without talking to the person who wrote it.
A sad notice today. I’ve retired Shopless from the AppStore. The reason is simple: I can’t afford the costs of the server that stores and syncs the data.