Skip to content

Commit

Permalink
Update blog content
Browse files Browse the repository at this point in the history
  • Loading branch information
bitomule committed Apr 23, 2020
1 parent 659aeca commit 18b0268
Show file tree
Hide file tree
Showing 3 changed files with 4 additions and 4 deletions.
4 changes: 2 additions & 2 deletions feed.rss
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content"><channel><title>Bitomule's learning shack</title><description>My thoughts about iOS, technology or any other thing that comes to my mind.</description><link>https://blog.bitomule.com</link><language>en</language><lastBuildDate>Thu, 23 Apr 2020 16:44:49 +0000</lastBuildDate><pubDate>Thu, 23 Apr 2020 16:44:49 +0000</pubDate><ttl>250</ttl><atom:link href="https://blog.bitomule.com/feed.rss" rel="self" type="application/rss+xml"/><item><guid isPermaLink="true">https://blog.bitomule.com/posts/introducing-swiftypods</guid><title>Introducing SwiftyPods: generate your podfile using Swift</title><description></description><link>https://blog.bitomule.com/posts/introducing-swiftypods</link><pubDate>Wed, 22 Apr 2020 19:36:00 +0000</pubDate><content:encoded><![CDATA[<h1>Introducing SwiftyPods: generate your podfile using Swift</h1><p>I’ve been working on this for weeks and today I am happy to finally share it with you.</p><p>SwiftyPods started with me exploring options to improve how we create feature modules at Wallapop. You can see my talk at NSSpain <a href="https://vimeo.com/showcase/6319394/video/362160599">here</a> about our approach to modules.</p><p>One of the first issues I saw is that our project had one single podfile including dependencies from main app and modules. We think that the long term solution will be getting our modules closer to Swift package manager but we are not there yet (hopefully SPM 5.3 with binaries support and assets will get us closer).</p><p>I have been interested in building a command line tool using Swift for long time, so it looked like the perfect opportunity to solve the problem using one.</p><p>I am not sure yet if it will be useful for us or if just and experiment. What I know is that I had a lot of fun building it.</p><p>Keep reading if you want some details about the implementation; if you just want to use it go to the repo at <a href="https://github.com/bitomule/SwiftyPods/blob/master/README.md">github</a> (I think I made it easy to use).</p><h2>DSL</h2><p>The domain specific language built for SwiftyPods is the first thing I created as a proof of concept and is one of the last things I finished. Right now I like the result although it is missing a lot of features.</p><p>I built it trying to be as close to Swift Package Manager and also trying to make it easier to grow in the future without breaking changes.</p><p>The result is:</p><pre><code><span class="keyword">let</span> podfile = <span class="type">Podfile</span>(
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content"><channel><title>Bitomule's learning shack</title><description>My thoughts about iOS, technology or any other thing that comes to my mind.</description><link>https://blog.bitomule.com</link><language>en</language><lastBuildDate>Thu, 23 Apr 2020 16:58:09 +0000</lastBuildDate><pubDate>Thu, 23 Apr 2020 16:58:09 +0000</pubDate><ttl>250</ttl><atom:link href="https://blog.bitomule.com/feed.rss" rel="self" type="application/rss+xml"/><item><guid isPermaLink="true">https://blog.bitomule.com/posts/introducing-swiftypods</guid><title>Introducing SwiftyPods: generate your podfile using Swift</title><description></description><link>https://blog.bitomule.com/posts/introducing-swiftypods</link><pubDate>Wed, 22 Apr 2020 19:36:00 +0000</pubDate><content:encoded><![CDATA[<h1>Introducing SwiftyPods: generate your podfile using Swift</h1><p>I’ve been working on this for weeks and today I am happy to finally share it with you.</p><p>SwiftyPods started with me exploring options to improve how we create feature modules at Wallapop. You can see my talk at NSSpain <a href="https://vimeo.com/showcase/6319394/video/362160599">here</a> about our approach to modules.</p><p>One of the first issues I saw is that our project had one single podfile including dependencies from main app and modules. We think that the long term solution will be getting our modules closer to Swift package manager but we are not there yet (hopefully SPM 5.3 with binaries support and assets will get us closer).</p><p>I have been interested in building a command line tool using Swift for long time, so it looked like the perfect opportunity to solve the problem using one.</p><p>I am not sure yet if it will be useful for us or if just and experiment. What I know is that I had a lot of fun building it.</p><p>Keep reading if you want some details about the implementation; if you just want to use it go to the repo at <a href="https://github.com/bitomule/SwiftyPods/blob/master/README.md">github</a> (I think I made it easy to use).</p><h2>DSL</h2><p>The domain specific language built for SwiftyPods is the first thing I created as a proof of concept and is one of the last things I finished. Right now I like the result although it is missing a lot of features.</p><p>I built it trying to be as close to Swift Package Manager and also trying to make it easier to grow in the future without breaking changes.</p><p>The result is:</p><pre><code><span class="keyword">let</span> podfile = <span class="type">Podfile</span>(
targets: [
.<span class="call">target</span>(
name: <span class="string">"Target"</span>,
Expand All @@ -17,7 +17,7 @@
)
]
)
</code></pre><p>There are some interesting details about it:</p><ul><li>Autocomplete does not work in 5.1, but as soon as I changed to 5.2 it started to work</li><li>It is crazy easy to add new options to dependency as the parameter is a variadic taking any amount of dependency configurations. Soon I will add better and safer versioning support without breaking changes</li><li>A child target is not the same as a target. This way it is impossible to set options like inheriting search paths in a target but it is possible in a child target.</li><li>I explored using function builders, but I did not see many improvements and I wanted to stay closer to SPM</li></ul><p>The first experiment was hardcoding a template inside the package and running the first command, generate. After some fixes is worked as expected so I moved on to the next feature.</p><p>##u Editing</p><p>Once I had a basic DSL, I noticed that in order to get the advantages from it I needed to build a way to edit those files.</p><p>I explored other tools, like Tuist, searching for options that solved similar problems.</p><p>I could not find an easy solution, but it turned up thanks to my good friend (and better engineer) <a href="https://github.com/hectr">Hector</a>: he suggested generating a package.swift and using it to edit files.</p><p>It worked and it was really easy, but it had two main issues:</p><ul><li>I wanted my solution to support having podfiles in multiple folders and this solution only allowed files in the same folder or at least in the same folder as the package.swift I was generating</li><li>Autocomplete was not working as expected and a Swift DSL without autocomplete was a half baked solution</li></ul><p>In order to solve the first problem and after talking with Hector again (yes, he helped me a lot during the development), he suggested using symbolic links to those files so Xcode will recognize them when the package.swift was opened.</p><p>That solved the issue excepting Xcode hates symbolic links; you can read them, but when you want to save changes the file is just not there for Xcode.</p><p>The way I solved it is not very elegant, but it works:</p><ol><li>When user runs the edit command I create a package.swift</li><li>Copy all the podfile.swift files to sources folder</li><li>Open the package.swift.</li><li>Wait for use finish editing confirmation in terminal</li><li>Copy files back to original paths and delete generated stuff</li></ol><p>That solved the issue with template files, but in order to solve the autocomplete issue I just had to go one step deeper with SPM: instead of generating a package.swift I had to use it to create a real Xcode project (yes, SPM can do that).</p><h2>Dependencies</h2><p>When you are building an app including or not a dependency has some implications, but user experience is not the main concern. In this case it was, either with a simple package.swift or a full Xcode project, editing meant downloading all the dependencies before you can compile your podfiles. Even worse, with a generated Xcode project you had to wait before even the project was open and you could start editing the file.</p><p>In order to improve the issue, I tried to reduce the number of dependencies by removing Stencil. I added it when I started working because the initial idea was more template focused than DSL, but the usage I was doing now was just replacing some text. I developed that small feature directly in my project and removed the dependency.</p><p>Just doing that reduced the time required to editing by a 60%.</p><h2>I know nothing</h2><p>During this development I have learnt more than expected as I got to dig a bit deeper in shell scripting and also I explored a lot of open source projects searching for ideas. I learnt that I knew nothing about command line scripting and now I know a bit more.</p><p>Thank you for reading and feel free to ask me through Twitter.</p>]]></content:encoded></item><item><guid isPermaLink="true">https://blog.bitomule.com/posts/getting-started-with-publish</guid><title>Getting started with publish</title><description></description><link>https://blog.bitomule.com/posts/getting-started-with-publish</link><pubDate>Fri, 17 Apr 2020 19:00:00 +0000</pubDate><content:encoded><![CDATA[<h1>Getting started with publish</h1><p>As you may have seen <a href="https://blog.bitomule.com/posts/moving-blog-again/">I’ve moved my blog again</a> and I’m using. <a href="https://github.com/JohnSundell/Publish">Publish</a>) ,an static website builder. But, what does static mean?</p><h2>Static website</h2><p>Static means that the website does not change while it’s deployed. There is no backend logic deciding what to render. It also means:</p><ul><li>Cheaper hosting as is just serving HTML + CSS</li><li>Free hosting using Github pages</li><li>Speed</li><li>Some features are not possible</li></ul><p>My old blog was already working like an static blog in terms of features but I had to host it on my own NAS. The speed was not bad due to my blog not having much traffic but any traffic increase would have made it crazy slow.</p><h2>Publish</h2><p>Now that we know what Publish offers, let me say that it’s far from being the first option in the market and it’s also far from being the most used or the one with the biggest community. You have tons of alternatives to build an static website and it’s not so difficult to do a custom one just for your site.</p><p>So, why did I use Publish then?</p><p>There is one big difference, something that makes Publish different: it is written in Swift. Not only the website generation is Swift, even the HTML is written using Swift because it uses <a href="https://github.com/johnsundell/plot">Plot</a>. This made me think that at least I should give it a try.</p><p>The exploring Publish task stayed in my “someday list” for months until my NAS hosted blog went down (I deleted the wrong docker and I had to restore it again which took me hours). That was the trigger that made me try Publish and I will try to explain it all in a series of posts; let’s get started:</p><h2>Getting started</h2><p>The first thing you need to do is cloning and building Publish using:</p><pre><code>$ git clone https://github.<span class="property">com</span>/<span class="type">JohnSundell</span>/<span class="type">Publish</span>.<span class="property">git</span>
</code></pre><p>There are some interesting details about it:</p><ul><li>Autocomplete does not work in 5.1, but as soon as I changed to 5.2 it started to work</li><li>It is crazy easy to add new options to dependency as the parameter is a variadic taking any amount of dependency configurations. Soon I will add better and safer versioning support without breaking changes</li><li>A child target is not the same as a target. This way it is impossible to set options like inheriting search paths in a target but it is possible in a child target.</li><li>I explored using function builders, but I did not see many improvements and I wanted to stay closer to SPM</li></ul><p>The first experiment was hardcoding a template inside the package and running the first command, generate. After some fixes is worked as expected so I moved on to the next feature.</p><h2>Editing</h2><p>Once I had a basic DSL, I noticed that in order to get the advantages from it I needed to build a way to edit those files.</p><p>I explored other tools, like Tuist, searching for options that solved similar problems.</p><p>I could not find an easy solution, but it turned up thanks to my good friend (and better engineer) <a href="https://github.com/hectr">Hector</a>: he suggested generating a package.swift and using it to edit files.</p><p>It worked and it was really easy, but it had two main issues:</p><ul><li>I wanted my solution to support having podfiles in multiple folders and this solution only allowed files in the same folder or at least in the same folder as the package.swift I was generating</li><li>Autocomplete was not working as expected and a Swift DSL without autocomplete was a half baked solution</li></ul><p>In order to solve the first problem and after talking with Hector again (yes, he helped me a lot during the development), he suggested using symbolic links to those files so Xcode will recognize them when the package.swift was opened.</p><p>That solved the issue excepting Xcode hates symbolic links; you can read them, but when you want to save changes the file is just not there for Xcode.</p><p>The way I solved it is not very elegant, but it works:</p><ol><li>When user runs the edit command I create a package.swift</li><li>Copy all the podfile.swift files to sources folder</li><li>Open the package.swift.</li><li>Wait for use finish editing confirmation in terminal</li><li>Copy files back to original paths and delete generated stuff</li></ol><p>That solved the issue with template files, but in order to solve the autocomplete issue I just had to go one step deeper with SPM: instead of generating a package.swift I had to use it to create a real Xcode project (yes, SPM can do that).</p><h2>Dependencies</h2><p>When you are building an app including or not a dependency has some implications, but user experience is not the main concern. In this case it was, either with a simple package.swift or a full Xcode project, editing meant downloading all the dependencies before you can compile your podfiles. Even worse, with a generated Xcode project you had to wait before even the project was open and you could start editing the file.</p><p>In order to improve the issue, I tried to reduce the number of dependencies by removing Stencil. I added it when I started working because the initial idea was more template focused than DSL, but the usage I was doing now was just replacing some text. I developed that small feature directly in my project and removed the dependency.</p><p>Just doing that reduced the time required to editing by a 60%.</p><h2>I know nothing</h2><p>During this development I have learnt more than expected as I got to dig a bit deeper in shell scripting and also I explored a lot of open source projects searching for ideas. I learnt that I knew nothing about command line scripting and now I know a bit more.</p><p>Thank you for reading and feel free to ask me through Twitter.</p>]]></content:encoded></item><item><guid isPermaLink="true">https://blog.bitomule.com/posts/getting-started-with-publish</guid><title>Getting started with publish</title><description></description><link>https://blog.bitomule.com/posts/getting-started-with-publish</link><pubDate>Fri, 17 Apr 2020 19:00:00 +0000</pubDate><content:encoded><![CDATA[<h1>Getting started with publish</h1><p>As you may have seen <a href="https://blog.bitomule.com/posts/moving-blog-again/">I’ve moved my blog again</a> and I’m using. <a href="https://github.com/JohnSundell/Publish">Publish</a>) ,an static website builder. But, what does static mean?</p><h2>Static website</h2><p>Static means that the website does not change while it’s deployed. There is no backend logic deciding what to render. It also means:</p><ul><li>Cheaper hosting as is just serving HTML + CSS</li><li>Free hosting using Github pages</li><li>Speed</li><li>Some features are not possible</li></ul><p>My old blog was already working like an static blog in terms of features but I had to host it on my own NAS. The speed was not bad due to my blog not having much traffic but any traffic increase would have made it crazy slow.</p><h2>Publish</h2><p>Now that we know what Publish offers, let me say that it’s far from being the first option in the market and it’s also far from being the most used or the one with the biggest community. You have tons of alternatives to build an static website and it’s not so difficult to do a custom one just for your site.</p><p>So, why did I use Publish then?</p><p>There is one big difference, something that makes Publish different: it is written in Swift. Not only the website generation is Swift, even the HTML is written using Swift because it uses <a href="https://github.com/johnsundell/plot">Plot</a>. This made me think that at least I should give it a try.</p><p>The exploring Publish task stayed in my “someday list” for months until my NAS hosted blog went down (I deleted the wrong docker and I had to restore it again which took me hours). That was the trigger that made me try Publish and I will try to explain it all in a series of posts; let’s get started:</p><h2>Getting started</h2><p>The first thing you need to do is cloning and building Publish using:</p><pre><code>$ git clone https://github.<span class="property">com</span>/<span class="type">JohnSundell</span>/<span class="type">Publish</span>.<span class="property">git</span>
$ cd <span class="type">Publish</span>
$ make
</code></pre><p>And then adding just create the folder where you want your blog to live and run publish new:</p><pre><code>$ mkdir <span class="type">MyWebsite</span>
Expand Down
Loading

0 comments on commit 18b0268

Please sign in to comment.