Merge branch 'master' of https://bitomule@github.com/bitomule/Blog

Output/feed.rss

@@ -1,4 +1,45 @@
-<?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>Sun, 3 May 2020 08:46:29 +0000</lastBuildDate><pubDate>Sun, 3 May 2020 08:46:29 +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[<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>Sun, 3 May 2020 08:49:01 +0000</lastBuildDate><pubDate>Sun, 3 May 2020 08:49:01 +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/automating-deploy-of-your-publish-site-to-github-pages</guid><title>Automating deploy of your publish site to github pages</title><description></description><link>https://blog.bitomule.com/posts/automating-deploy-of-your-publish-site-to-github-pages</link><pubDate>Fri, 1 May 2020 10:05:00 +0000</pubDate><content:encoded><![CDATA[<p>This is the second post about Publish, the static website building tool by John Sundell.</p><p>I have already shared how to <a href="https://blog.bitomule.com/posts/getting-started-with-publish/">get started</a> and today we will focus on publishing the website.</p><p>As today Publish does not include an official method to deploy to <a href="https://pages.github.com/">github pages</a> but a <a href="https://github.com/JohnSundell/Publish/pull/74">PR is already open</a>. Although we don’t have that support we can publish just using the github deploy method.</p><h2>Creating the repo</h2><p>In order to deploy your blog in Github Pages you have to create a new repository where only the published blog will live. This means that if you already have a repo with your site source code, you will have to create a new one to host the static files.</p><p>Just create an empty Github repository and you are good to go.</p><h2>Deploy</h2><p>On the previous post we created our own theme, but we didn’t focus much in the publish method. It may look like this right now:</p><pre><code><span class="keyword">try</span> <span class="type">Blog</span>().<span class="call">publish</span>(
+    withTheme: .<span class="dotAccess">blog</span>
+)
+</code></pre><p>This is just enough to generate a site that you can manually upload to whatever hosting you choose. If you want publish to deploy the site for you, you need to add the deployUsing argument. In our case we want to deploy using github so it will look like:</p><pre><code><span class="keyword">try</span> <span class="type">Blog</span>().<span class="call">publish</span>(
+    withTheme: .<span class="dotAccess">blog</span>,
+    deployedUsing: .<span class="call">gitHub</span>(<span class="string">"yourusername/yourrepo"</span>),
+)
+</code></pre><p>Use the repo you have just created as the target repository and now you can just run:</p><pre><code>publish deploy
+</code></pre><p>Then Publish will deploy the generated files to your empty repo. You can use this command each time you want to deploy your site.</p><h2>Enabling github pages</h2><p>In order to activate your site, you have to enable Github Pages for the repository with your static files. To do that just go to your repository settings, scroll down to GitHub Pages and configure it. You can use a custom domain if you want to and choose master as the source (that is why you have a repo with site content only).</p><p>This will create a CNAME file in your repository telling GitHub the domains it can handle. Also keep in mind you will have to change your domain DNS CNAME registry to your Github page url.</p><p>If you prefer to use https with a custom domain you will have to use <a href="https://www.cloudflare.com/">Cloudflare</a> (A free CDN service) that will also improve your site speed. Please <a href="https://twitter.com/bitomule">let me know</a> if you are interested in a blog post about the Cloudflare setup.</p><h2>Automating</h2><p>Right now you should have your website running, available to the public and deployed using a one line command.</p><p>This is good enough for most people, but we can go one step further and make it automatic so a new website version will be deployed each time we commit changes to our blog repository.</p><p>We can do this for free using <a href="https://github.com/features/actions">Github Actions</a>. We will create a new Github Action workflow in the repo that hosts our blog source that will:</p><ul><li>Launch a macOS virtual machine</li><li>Checkout our repo</li><li>Generate static files</li><li>Publish to your Github Pages repository</li><li>Commit changes to source repo (you can skip this one and ignore output folder in your source repo)</li></ul><p>In order to create your first Github Action, go to the Actions tab in your source repo and tap New Workflow. You may choose the getting started Workflow and delete all the content.</p><p>Here you have the YAML file I use in my own repo:</p><pre><code>name: <span class="type">Publish</span>
+
+on:
+  push:
+    branches: [ master ]
+
+jobs:
+  build:
+    runs-on: macOS-latest
+
+    steps:
+    - uses: actions/checkout@v2
+
+    - name: <span class="type">Generate</span> blog
+      run: swift run <span class="type">Blog</span>
+    - name: <span class="type">Publish</span> <span class="keyword">in</span> github pages repo
+      uses: crazy-max/ghaction-github-pages@v1.<span class="number">4.0</span>
+      with:
+        repo: youruser/yourrepository
+        target_branch: master
+        keep_history: <span class="keyword">true</span>
+        allow_empty_commit: <span class="keyword">false</span>
+        build_dir: <span class="type">Output</span>
+        committer_name: yourname 
+        commit_message: <span class="type">Update</span> blog content
+      env:
+        <span class="type">GITHUB_PAT</span>: ${{ secrets.<span class="type">REPO_TOKEN</span> }}
+
+    - name: <span class="type">Add</span> &amp; <span class="type">Commit</span> changes
+      uses: <span class="type">EndBug</span>/add-and-commit@v4.<span class="number">0.1</span>
+      with:
+        author_name: yourname
+        message: <span class="type">Commit</span> new output
+</code></pre><p>The last step to get this working is <a href="https://help.github.com/en/enterprise/2.17/user/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line">creating a Github token</a> with access to your Github Page repository and adding it inside your source repository Secrets as REPO_TOKEN (you can find secrets inside your repository settings).</p><p>Now each time you commit to the master branch of your source repository Github will publish the content for you. Isn’t it awesome?</p><h2>Drafts</h2><p>Automation feels like magic as you no longer have to go through Publish, but it also means that each time you commit your blogpost it will get published and all your readers can see it. To avoid this I created a drafts folder next to my blogposts. It is still possible to read them if people gets into the repository, but they are not available in the published website.</p><p>You can also use branches and even create pull requests if that makes sense to you.</p><h2>iPad blogging</h2><p>I’m not going to lie, I added all this automation because I wanted to write my blogposts using my iPad and running publish deploy from the iPad is just not possible (as today 😛).</p><p>My setup is quite easy but works really well:</p><ul><li>I use <strong>Working copy</strong> to manage the repository. It is not a cheap application, but it does an amazing job if you want to have a git repository on your iOS device. The best feature of Working copy is that it shares you repository as a resource inside Files app and that means you can open and edit files from your repo inside other apps.</li><li>That other app, in my case, is <strong>iA Writer</strong>. I’ve been trying multiple markdown editing applications, but iA Writer has the support to open folders from Files sources and that is just what I need. I just have 2 folder references inside iA Writer: posts and drafts.</li><li>I have a custom shortcut to create metadata for each blog</li></ul><p>So the process when I want to start a new blog post is: 1. Run a shortcut from my iPad home screen 2. Type tile and tags (I want to improve this step using Data Jar to have some already defined tags) 3. The shortcut opens iA Writer for me so I just have to create a new draft, paste metadata and start Writing.</p><p>Once the draft is ready to be published I just move it to the posts folder, push my repository to remote and Github Actions takes care of publishing it.</p><p>I hope you have enjoyed reading this and it helps you improve your blogging flow so you can share more interesting content with all your readers. Please let me know if you want to know more about something or there is something you missed 🙂.</p>]]></content:encoded></item><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[<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>,