codethoughts.io Open in urlscan Pro
2606:4700:3035::ac43:aceb  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Christian Kjær Laustsen — GitHub — LinkedIn

Want to reach me? 👇 Scroll to the bottom of this page to find out more!


Recent posts on the blog
 * How I structure work as a Solo Founder
   
   This is for sure something that will keep evolving over time, but I got
   inspired by this Hacker News post to share in more detail how I organize
   myself and my work (you can see my short answer here).
   
   The question posed is great, so let’s start from there:
   
   > When working with a team, I've found that Scrum-like short-term goals and
   > organized task backlogs really help keep me focused and on track with the
   > work I have to do. For solo development, however, I've never really found
   > any approach that sticks and often end up getting sidetracked and losing
   > track of my objectives.
   > 
   > So my question to all of you is, what tools and techniques have you used to
   > ensure you stick to your objectives?
   
   You could rephrase this slightly to: How do I run my own project management?
   
   For most Engineers, this is not actually something they’ve needed to do
   often, especially if working in larger corporations. The people that have
   worked at Startups are a mixed bag, where some learn the value of structure,
   and others managed to get by without since the fast-paced environment changes
   things around all the time anyways.
   
   I’ve personally landed in the camp of: Structure is valuable, even crucial,
   but it should never get in my way. Best of both worlds sorta.

 * Mobile: A different way using Rust?
   
   After having spent the better part of two months deep in the trenches of iOS
   development with Swift, I can comfortably say: Web Development simply is more
   mature.
   
   Let’s just run over a few things I ran into that’s bad, broken, or made for a
   poor experience:
   
    * A lot of issues with data handling in general
      * Turning iCloud on when using SwiftData will restrict core functionality
        such as the ability to have unique IDs on your data, meaning everyone
        now has to handle duplicates
      * iCloud (CloudKit) and data migrations don't work really work, it just
        won’t run it making data changes in your models quite the chore
      * SwiftData generally has very bad performance, both in reads, writes, and
        inserts
      * It’s quite hard to control memorization and rendering performance (e.g.
        @Query in your View)
    * Swift itself is a bit of an eh language - it has many good parts and
      ergonomics, but also some weird design choices that make scaling codebases
      messy such as everything by default living in the global namespace and
      file names can’t clash
    * SwiftUI is generally great, except when you want to do anything
      non-standard, in which case you’ll quickly feel the pain
    * The feedback loop is slow: If you can run things in the Preview that’s the
      fastest, otherwise it’s a full Compile→Run→Simulator loop
    * UI performance issues are very easy to sneak in, and very hard to track
      down
    * Apple’s frameworks sure do have a lot of bugs and you’ll commonly see
      stuff being broken almost permanently
   
   Admittedly, these might be trivial gripes for someone that has spent years in
   the Mobile ecosystem, but they certainly didn’t make me fall in love with it.
   More importantly, it wasn’t really providing a great user experience either.
   
   ….so what’s the alternative?

 * Setting up UniFFI for iOS, Simulators, and watchOS
   
   This is a part of the post Mobile: A different way using Rust?.
   
   There are some great resources out there on UniFFI already such as this post,
   but it doesn’t cover watchOS, so let’s take a quick tour through what I’ve
   set up in the example repository
   https://github.com/Tehnix/template-mobile-wasm.
   
   We've set up four crates:
   
    * appy: Our Leptos App, Capacitor, and the XCode project
    * capacitor-rs: Bridging code between the Capacitor JS library and our Rust
      code
    * shared: Our shared code that we might use in appy, and also want to expose
      in Swift to use in our Widgets or watchOS App
    * mobile: Where we will generate the Swift bindings from via UniFFI,
      reexporting everything from shared that’s made available to UniFFI via the
      macros
   
   I won’t go over the details to get these to play nicely with Cargo and
   Workspaces, check out the repository for that. Let’s instead focus on a
   simplified version of what mobile does (the rest assumes you’re in the
   mobile/ directory).

 * Using Capacitor Plugins from Rust/WASM
   
   This is a part of the post Mobile: A different way using Rust?.
   
   Capacitor is normally used in combination with JavaScript projects, so there
   is little help available if you want to use it in a Rust/WASM project. Worry
   not! That's exactly what we'll take a look at in this post.
   
   Since Capacitor is a JS framework there will be a little extra work involved
   in interacting with any plugins, but it’s honestly not a lot we need to do.
   Let’s take a quick tour through what I’ve set up in the example repository
   https://github.com/Tehnix/template-mobile-wasm.

 * The Stack Part 3: Building a Frontend
   
   In the last post we set up our deployment, fully automated on merge to our
   main branch. In this post we will be building our UI (Frontend) applications.
   See the full overview of posts here.
   
   At the end of this post we will have:
   
    * A Next.js Frontend app with support for localization, using Tailwind CSS.
    * A Leptos Rust/WASM Frontend app with support for localization, using
      Tailwind CSS.
    * Automatic deployment of our Apps AWS using CDK, statically hosted using S3
      + CloudFront.
   
   We are essentially hedging our bets by building both a JavaScript-based
   Frontend, which is the safe bet, and a Rust/WASM-based Frontend, which is the
   future bet. We will be using the same GraphQL API for both, so we can easily
   switch between them.
   
   There is quite a lot to cover. My recommendation is to clone down the Part 3
   branch in the GitHub repository and use this post as an explanation of what
   is set up.

 * The Stack Part 2: Automating Deployments via CI
   
   In the last post we created our Control Tower structure with all of our AWS
   Accounts in it. In this post we will be automating our deployment process for
   each of these environments. See the full overview of posts here.
   
   At the end of this post we will have:
   
    * A workflow for bootstrapping our AWS Accounts for CDK (see here).
    * A workflow for deploying our CDK stacks, including synthesizing and
      testing before (see here).
    * Set up automatic staggered deployments when changes are merged to our main
      branch.
    * And fallback to manual deployments if we need to.
   
   If you want to jump straight to the code, you can find it in the GitHub
   repository which links directly to the Part 2 branch.
   
   Otherwise, let's jump in!

 * The Stack Part 1: Setting up your AWS Account Structure
   
   In the last post we went over the overall goals of "The Stack" and what we
   will be building. In this post we'll be setting up our AWS Account structure.
   See the full overview of posts here.
   
   As a reminder, here is the structure we are aiming for:
   
    * Control Tower: This is your central place to control access and policies
      for all accounts in your organization
    * Production Multi-tenant: Your primary production account for multi-tenant
      setup, and most likely were the majority of users will be
    * Production Single-tenant: While desirable to avoid the operation overhead
      for single-tenant setups, its good to think in this from the get-go
    * Integration Test: This will be the account that IaC deployments get tested
      on to ensure rollout works
    * Preview: This will be used to spin up Preview Environments later on
    * Individual Developer: Individual developer accounts to allow easy testing
      of IaC testing and exploration
    * Monitoring: Centralize monitoring and observability into one account,
      allowing access to insights without access to sensitive logs or
      infrastructure from the other accounts
    * Logs: Centralized storage of logs, which may require different access
      considerations than metrics and traces

 * View more...

Interesting projects
 * Rust on Mobile with WASM
   Template project for building a Rust application that can be run on Web, iOS
   and Android using Leptos, Capacitor and UniFFI
 * Serverless Federated GraphQL
   Comparison of Federated GraphQL solutions for serverless, featuring a minimal
   build of Apollo Router built for Lambda via Amazon Linux 2, and comparison to
   other alternatives (Cosmo, Mesh, Gateway)
 * Serverless Rust / ...+ Graphql
   Setup for starting with serverless Rust + GraphQL + DynamoDB on AWS Lambda
   using AWS CDK for deployment
 * SpaceNeovim / ...+ Layers
   Spaceneovim is a Spacemacs inspired distribution for Neovim
 * Mobile Haskell
   Toy project for testing out Haskell on iOS
 * RF+1 App
   Mobile app (React Native) helping people meetup for concerts, developed for
   Roskilde Festival
 * HsCMS
   A CMS implemented in Haskell using the Yesod framework
 * TowerOfPower
   A small fun Unity3D game in Pokémon style 2D graphics

Getting a hold of me

I can be found many places! Hit me up on twitter at @codetalkio or Mastodon; tag
me in an issue on GitHub with @Tehnix; or simply shoot me an email to contact AT
codetalk DOT io

about the site
archive of all posts
overview of tags

personal github and
codetalk projects
twitter feed

© copyright codetalk 2024