profile
viewpoint
Pete Goldsmith raven Itty Bitty Apps Melbourne, Australia

wokalski/Diff.swift 935

The fastest Diff and patch library in Swift. Includes UICollectionView/UITableView utils.

FeatherweightLabs/FeatherweightRouter 101

Clean Swift Router and Coordinator for declarative routing tree matching

raven/Changeset 0

Minimal edits from one collection to another

raven/danger 0

🚫 Stop saying "you forgot to …" in code review

raven/Diff.swift 0

The fastest Diff and patch library in Swift. Includes UICollectionView/UITableView utils.

raven/emojis 0

:shipit: Custom emoji supported by Buildkite which you can use in your build pipelines and terminal output.

raven/Eureka 0

Elegant iOS form builder in Swift

raven/fastlane 0

🚀 The easiest way to automate building and releasing your iOS and Android apps

raven/FeatherweightRouter 0

Clean Swift Router and Coordinator for declarative routing tree matching

raven/findxcprojorphan 0

Finds source files unreferenced in Xcode project

Pull request review commenttuist/tuist

Add new principle to the manifesto: "Start from the developer's experience"

 Xcode is a great tool, but so many years of improvements, new platforms, and pro  Tuist should take the opportunity to keep things simple because working on simple things is fun and motivates us. No one wants to spend time trying to debug an error that happens at the very end of the compilation process, or understanding why they are not able to run the app on their devices. Xcode delegates the tasks to its underlying build system and in some cases it does a very poor job translating errors into actionable items. Have you ever got a “framework X not found” error and you didn’t know what to do? Imagine if we got a list of potential root causes for the bug. -## 5. We are not a project generation tool+## 5. Start from the developers' experience -The generation of Xcode projects is a mean and not an end in itself. Our goal is not to provide developers with another language to define their projects but rather, help them cope with the challenges they face when they scale up their projects. That means we might not provide APIs for all the features supported by Xcode, and that's fine. If we did, we'd be re-writing Xcode projects in a new language, and that's a task that falls into Apple's domain.+Part of the reason why there is a lack of innovation around Xcode, or put differently, not as much as in other programming environments, is because **we often start analyzing problems from existing solutions.** As a consequence, most of the solutions that we find nowadays revolve around the same ideas and workflows. While it’s good to include existing solutions in the equations, we should not let them constrain our creativity. -That means we sometimes have to say no to bringing ideas from Xcode that complicate scaling. For instance, if dealing with code signing at scale is something that Xcode doesn't do well, let's take the opportunity to re-think how code signing is done.+We like to think as [Tom Preston](https://tom.preston-werner.com/) puts it in [this podcast](https://tom.preston-werner.com/): _"Most things can be achieved, whatever you have in your head you can probably pull of with code as long as is possible within the constrains of the universe"_. If we imagine **how we'd like the developer experience to be**, it's just a matter of time to pull it off — starting analyzing the problems from the developer experience gives us a unique point of view that will lead us to solutions that users will love to use. -We might feel tempted to follow what everyone is doing, even if that means keeping on with the inconveniences that everyone continues to complain about. Let's not do that. Let's imagine how day-to-day tasks would be handled by Tuist. _How do I imagine archiving my app?_ _How would I love code signing to be?_ _What processes can I help streamline with Tuist?_ If we constrain our solutions to what we have seen in other tools, we might end up replicating the same inconveniences and issues that make scaling up Xcode projects a challenge.-We'll often see users opening tickets with solutions rather than problems. Whenever that happens, use "why" questions to understand what are the user's motivations or needs. For example, a request from a user could be: Add support for linking libraries build phases. That's a solution to the need the user has to define dependencies between targets. Once we have identified that, we can think if Xcode's approach to defining dependencies is good at scale, and if it's not, we can discuss with the user better approaches.+We might feel tempted to follow what everyone is doing, even if that means keeping on with the inconveniences that everyone continues to complain about. Let's not do that. _How do I imagine archiving my app? How would I love code signing to be? What processes can I help streamline with Tuist?_ For example, adding support for [Fastlane](https://fastlane.tools) is a solution to a problem that we need to understand first. We can get to the root problem or need by asking "why" questions. Once we narrow down where the motivation comes from, we can think of how Tuist can help them best. Maybe the solution is integrating with Fastlane, but it's important we don't disregard other equally valid solutions that we can put on the table before making trade-offs.

means keeping on with -> means sticking with

We might feel tempted to follow what everyone is doing, even if that means sticking with the inconveniences that everyone continues to complain about. Let's not do that. _How do I imagine archiving my app? How would I love code signing to be? What processes can I help streamline with Tuist?_ For example, adding support for [Fastlane](https://fastlane.tools) is a solution to a problem that we need to understand first. We can get to the root of the problem by asking "why" questions. Once we narrow down where the motivation comes from, we can think of how Tuist can help them best. Maybe the solution is integrating with Fastlane, but it's important we don't disregard other equally valid solutions that we can put on the table before making trade-offs.
pepibumur

comment created time in a month

Pull request review commenttuist/tuist

Add new principle to the manifesto: "Start from the developer's experience"

 Xcode is a great tool, but so many years of improvements, new platforms, and pro  Tuist should take the opportunity to keep things simple because working on simple things is fun and motivates us. No one wants to spend time trying to debug an error that happens at the very end of the compilation process, or understanding why they are not able to run the app on their devices. Xcode delegates the tasks to its underlying build system and in some cases it does a very poor job translating errors into actionable items. Have you ever got a “framework X not found” error and you didn’t know what to do? Imagine if we got a list of potential root causes for the bug. -## 5. We are not a project generation tool+## 5. Start from the developers' experience -The generation of Xcode projects is a mean and not an end in itself. Our goal is not to provide developers with another language to define their projects but rather, help them cope with the challenges they face when they scale up their projects. That means we might not provide APIs for all the features supported by Xcode, and that's fine. If we did, we'd be re-writing Xcode projects in a new language, and that's a task that falls into Apple's domain.+Part of the reason why there is a lack of innovation around Xcode, or put differently, not as much as in other programming environments, is because **we often start analyzing problems from existing solutions.** As a consequence, most of the solutions that we find nowadays revolve around the same ideas and workflows. While it’s good to include existing solutions in the equations, we should not let them constrain our creativity. -That means we sometimes have to say no to bringing ideas from Xcode that complicate scaling. For instance, if dealing with code signing at scale is something that Xcode doesn't do well, let's take the opportunity to re-think how code signing is done.+We like to think as [Tom Preston](https://tom.preston-werner.com/) puts it in [this podcast](https://tom.preston-werner.com/): _"Most things can be achieved, whatever you have in your head you can probably pull of with code as long as is possible within the constrains of the universe"_. If we imagine **how we'd like the developer experience to be**, it's just a matter of time to pull it off — starting analyzing the problems from the developer experience gives us a unique point of view that will lead us to solutions that users will love to use.

you can probably pull of with code -> you can probably pull off with code

starting analyzing the -> by starting to analyze the

We like to think as [Tom Preston](https://tom.preston-werner.com/) puts it in [this podcast](https://tom.preston-werner.com/): _"Most things can be achieved, whatever you have in your head you can probably pull off with code as long as is possible within the constrains of the universe"_. If we imagine **how we'd like the developer experience to be**, it's just a matter of time to pull it off — by starting to analyze the problems from the developer experience gives us a unique point of view that will lead us to solutions that users will love to use.
pepibumur

comment created time in a month

Pull request review commenttuist/tuist

Add new principle to the manifesto: "Start from the developer's experience"

 Xcode is a great tool, but so many years of improvements, new platforms, and pro  Tuist should take the opportunity to keep things simple because working on simple things is fun and motivates us. No one wants to spend time trying to debug an error that happens at the very end of the compilation process, or understanding why they are not able to run the app on their devices. Xcode delegates the tasks to its underlying build system and in some cases it does a very poor job translating errors into actionable items. Have you ever got a “framework X not found” error and you didn’t know what to do? Imagine if we got a list of potential root causes for the bug. -## 5. We are not a project generation tool+## 5. Start from the developers' experience
## 5. Start from the developer's experience
pepibumur

comment created time in a month

issue openedtuist/tuist

Add ability to generate Command Line Tool product types

Need

I'd like to see Tuist have the ability to create Command Line Tools.

image

Motivation

When working on iOS apps, I occasionally create a macOS Command Line Tool as an alternative "interface" to the application core frameworks. I have also recently been experimenting with spinning up CLIs for interacting with running iOS apps, as per: https://rambo.codes/posts/2020-03-01-writing-command-line-interfaces-for-ios-apps

Detailed design

This would involve extending the Product enum with a .commandLineTool case, and all that flows from that. (Currently researching what is involved)

Drawbacks

This will further add complexity to the Product type.

Alternatives

Generating Command Line Tool targets manually via Xcode outside of the tuist workflow. This is less than ideal in the use cases I've highlighted above where it makes sense to

Adoption strategy

This isn't a breaking change, should be purely additive.

How we teach this

Documentation should be updated to highlight this capability.

created time in a month

PR opened tuist/tuist

Correct macOS fixture class name

Short description 📝

Noticed that the macOS fixture defined a class with name watchOS.

Solution 📦

s/watchOS/macOS/g

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchtuist/tuist

branch : correct-fixture-classname

created branch time in 2 months

push eventrealestate-com-au/mediamath-ios-sdk

Peter Goldsmith

commit sha 01792bc3076049a923950bc94189ff7b923796b7

Add InHouse configuration

view details

push time in 2 months

push eventraven/mediamath-ios-sdk

Peter Goldsmith

commit sha 63d58377d46ad67f47d843ec88fdf4d5c10a4a8d

Add InHouse configuration

view details

push time in 2 months

PR opened buildkite/emojis

Add :firebase:

Adds emoji for Firebase

firebase

+7 -0

0 comment

3 changed files

pr created time in 3 months

create barnchraven/emojis

branch : add-firebase

created branch time in 3 months

fork raven/emojis

:shipit: Custom emoji supported by Buildkite which you can use in your build pipelines and terminal output.

https://buildkite.com/

fork in 3 months

more