DEV Community: Ghost

Aphantasia, without mental imaginary

Ghost — Tue, 25 Feb 2020 21:10:54 +0000

I'm over 30 and I just learned that my mind doesn't work like most.

This post will have a lot of "I" on it, will be very subjective but that is the very core of the thing.

My whole life phrases like "picture in your mind", "visualize" and even "happy places", where figurative speech. Have you felt like everybody but you got a memo, that everyone are playing by some rulebook you never got?, apparently most people can actually see pictures in their head, when people imagine being on a beach, can actually see, hear and/or oven smell it, with different levels of detail and control.

You may think, so what?, but if you are like me and you haven't realized yet, you should be getting some really weird feelings and maybe some things are starting to make sense somehow. All I can see with my eyes closed is black, just my eyelids from inside, I can't see pictures, 3D objects, not even a simple circle, not a sound, not a smell and not emotional connection with memories; I can recall past event of course, but just as if someone else where telling me.

I never knew until now because I never had problems with spatial tasks, I actually excel on some of them, when I need to know how would a 3D object be rotated I just know, but I can't "see" it, no image forms in my mind, and until very recently I thought that it was the same of everyone. Talking with my mother yesterday, she explained me how she can close her eyes and "see" herself in a lake and even her feet under the water, full color, Ray Tracing activated and even with smells!, after some DDG searching (I refuse to make a verb out of the G word), I find out that is not her superpower, is my underpower?, apparently there are not many studies about it, aphantasia is now called and from 2% to 5% have it, most of us don't know it and some realize much older than me, some never find out.

But wait a minute, so if I'm like that I'm somehow inferior of lesser?, hell no, I've noticed and is maybe related, that I can't hold grudges, probably because there are no emotions related to memories, they are just facts to me and is no specially interesting to delve in them, in fact I've never spend much time in the past (well in fact all my life is in my past, but you get what I mean) and thinking about the future is just about facts for me, cold planning; kinda zen out of the box; no constant and distracting multimedia feed in my head, just my own inner voice (not heard but still there) an interesting background narration and even group conversations with "simulated" people in my head.

Maybe that's why some of us need or prefer more graphical information, we need those diagrams and graphs made for us, our minds can't draw them, or at least doesn't share the video feed with us. Is like the visual process is running in the background. I dream in multimedia but some can't even do that, some can "see" but not "hear", some can do all of them and in different degrees.

I'm just finding this out, maybe some of you are realizing it now, maybe if you ask around you'll find others, it may help you understand yourself better and think how to work with others.Maybe you felt inadequate and it was just that you have been using the wrong "tools" or feeling dumb because techniques used by others are not a good fit for you. Aphantasia has his pros and cons just like being an Aspie, don't let other to convince otherwise. We are weird, deeply weird, and that is not fine, is better than fine, is awesome, nothing normal ever caused awe, haven't it?.

Rust: Project structure example step by step

Ghost — Sat, 18 Jan 2020 23:47:55 +0000

Introduction

The recent, hopefully temporal, death of Actix-web forced me to recheck some code of a pet project of mine that was not cleanly decoupled, some of my Diesel was mixed with my Actix, so I will share the process and stages of decomposition in Rust.

This is thoroughly explained in The Book, but I'll try to make it more concise and simple, I'll skip many details in favor of clarity and of course the code itself is not useful, its only purpose is to show as simple as I could, the process step by step. I hope is helpful.

I also uploaded a repo in github (https://github.com/robertorojasr/rust-split-example), if you clone it, each commit is another step in the process. And unlike this example, it runs (doesn't do much but runs)

This evolution should look like this:

Single file with everything on it.
Move part of your code to a different module. (this step is missing in the repo, I forgot, sue me), please don't sue me.
Move the module to a different file.
Turn the module in a single file into a folder acting as a module with multiple files as sub-modules.
Split your crate in a library and an executable that lives in the same directory tree.
Move the executable and library to different crates (workspaces) with their own directory tree.

When our project gets bigger and more complex this strategies will help to keep the overall structure of your code manageable, clear and decoupled.

0. Starting point

So you make you "Hello World" and everything is cool, you replace that println and start coding, soon you notice your lovely main.rs is getting bigger, filled with structs, functions and traits, some of them are link to each other but some are not, like Neo watching the Matrix you start to see some macro-structure and you tell to yourself, "myself, is time to tide this mess", of course you could design all before you start, (you should actually), but you want avoid overengineering and as this post shows (at least hopes to) is not necessary to take the big guns from the start.

Lets say this is your current masterpiece, impressive, I know, I did it all by myself.

// src/main.rs

struct A {
    a: i32,
}

struct B {
    b: i32,
}

fn main() {
    let first = A { a: 42, };
}

1. A module

So how do you start?, the first thing would be make modules to encapsulate some code

// src/main.rs

mod something {
    struct A {
        a: i32,
    }

    struct B {
        b: i32,
    }
}

fn main() {
    let first = A { a: 42, };
}

but now there is a problem, even tho A is defined in the same file, is no longer in the same module, so main() have no idea something is in there, so we have to import something

// src/main.rs 

mod something {
    struct A {
        a: i32,
    }

    struct B {
        b: i32,
    }
}

use crate::something::*; // <- this is new

fn main() {
    let first = A { a: 42, };
}

Now main() knows that something is here and that it can use everything public in there, but wait, there is nothing public in there, so we have to make public whatever we want to make visible to main().

// src/main.rs 

mod something {
    pub struct A { // <- this is new
        pub a: i32, // <- this is new
    }

    pub struct B {
        pub b: i32, // <- this is new
    }
}

use crate::something::*;

fn main() {
    let first = A { a: 42, };
}

Now main() can see everything inside, of course you don't have to make all public, just what you need, and spare me the OOP argument that you shouldn't expose data, is just an example here, and OOP is not all there is BTW (a bit of sass here).

2. A module in other file

But that doesn't solve the fact that your IDE gets laggy with your still huge file, in fact you just added more stuff!, to solve this you should start using Vim... I joking... (Am I?)

So now you want to move that module outside, to other file, to live free and alone.

So you keep the definition and the import in main.rs

// src/main.rs

mod something;
// the content of the module was here

use crate::something::*;

fn main() {
    let first = A { a: 42, };
}

and put the module content in your freshly made new file in the same folder as main.rs

// src/something.rs 

pub struct A {
    pub a: i32,
}

pub struct B {
    pub b: i32,
}

When you added the module something in main.rs

// src/main.rs

mod something;

// the rest of it

Rust automagically looks for it inside the file, if doesn't find it, looks for a file with the module name in the same folder (in this case src/) and if still doesn't find it looks for a folder with the module name and a file mod.rs inside, there it looks for the code.

3. A module in a folder with many submodules

As mentioned in the last paragraph, we can split even more our module,
all we have to do is make a folder something so we get:

src/
 |_ main.rs
 |_ something.rs
 |_ something/

Now, we could just rename something.rs as mod.rs and move it inside something/ but what's the point in that, we want to split things!, so we are gonna give A and B, (please don't name your stuff like that outside examples like this) their own modules. So we'll have this tree

src/
 |_ main.rs
 |_ something/
     |_ mod.rs
     |_ a.rs
     |_ b.rs

But what happen with something.rs, well my friend, you split it, A goes to a.rs and you can guess where B went.

Now A and B are in their own modules so we modify the imports accordingly

// src/main.rs

use crate::something::a::*; // <- this is new
use crate::something::b::*; // <- this is new

fn main() {
    let first = A { a: 42, };
}

But mod.rs has now the responsibility to call their children, as I told before, when Rust check for something.rs and doesn't find it will check for the folder something and then inside look for a file named mod.rs.

// src/something/mod.rs

pub mod a;
pub mod b;

You may notice that this is the same thing we did with main at first. You can keep nesting modules as long as you like, just like that.

// src/something/a.rs

pub struct A {
    pub a: i32,
}

// src/something/b.rs

pub struct B {
    pub b: i32,
}

Fine and dandy, but now what? what if my project is a huge beast, what if I could reuse some of the code, let's say. You had a nice webapp with Diesel ORM and Actix-web on top, what is some day, let say Actix creator leaves and it's future is uncertain, what then huh?, what then?!

...

Well, you could see your webapp as a library that deals with the DB, lets say with Diesel and a separate consumer in an executable with Actix-web or other framework that is not apparently dead, but maybe comes back ...

You could also make a CLI UI for example that will use the same DB related codebase. Lets do it!

4. Rust library with an executable file

As you may have read and skip to more fun stuff, Rust recognize 2 kinds of crates (the official name of what I've been calling project, just because I'm a rebel) libraries and executables, you probably know the difference but for completion let put it simple, an executable is something you use directly and a library is something that is used by an executable.

What we want in this case is to put our main() in another file as an executable and leave all of our structs in a library for future reuse in other executables.

Rust tries really hard to make things easy (because it feels guilty for all the suffering with burrows and lifetimes) so to make a crate a lib you just rename the file main.rs to lib.rs, voilá, now is a library, but lets make something useful with it, to do that, we'll make a new folder bin/ and we will copy our existing main.rs, (now renamed lib.rs) on it with some fancy and descriptive name, leaving you with this new tree:

src/
 |_ lib.rs // <- just a renamed main.rs
 |_ bin/ // <- this folder is new
 |_  |_ framework_that_broke_my_heart.rs // <- a copy of our ex-main.rs
 |_ something/
     |_ mod.rs
     |_ a.rs
     |_ b.rs

so, everything inside something/ will be untouched now, first we'll work in framework_that_broke_my_heart.rs. The first thing will notice is that everything inside bin/ is in a bubble universe, even tho is inside our crate is not part of it anymore, think it like us and society (not you, well adjusted programmers..ugh), so we have to call our newly created library (you know, when we renamed main.rs to lib.rs) just as we where calling any library.

// src/bin/framework_that_broke_my_heart.rs

extern crate this_example; // oh right, I never named
// this crate, is the name you give in Cargo.toml
// under [package] in tha *name* field
// (don't use dashes on it)

use crate::something::a::*;
use crate::something::b::*;

fn main() {
    let first = A { a: 42, };
}

and in lib.rs ex-main.rs

// src/lib.rs

pub mod something; // <- this is all, is like telling Rust
// copy/paste everything inside `something` inside a `mod` here

Everything inside something is untouched.

We are close to the finish line, by now you may have wondered about the situation of that poor fellow whose heart was broken by the early demise of his favorite framework, and telling yourself, how the F* did he put all his Actix-web code inside a tiny little file, that file must be huge, a huge mess, but the whole idea was to split things and he just made everything worse!, well my fellow, this is when the next point comes.

5. Workspaces

This turns you crate in smaller crates inside a big crate-ish umbrella, you could just split your code in 2 crates by now, after all, we claimed that the executable in the later step was already not part of the original crate and that's right. Spliting entirely the code in 2 separate crates is a valid choice, but many of the dependencies are common to both: the executable and the library; and it would be annoying to rebuild 2 times, test 2 times, etc. If both the library(es) and executable(s) are related to each other, you may want to treat them as 1 thing for building/testing/running purposes, you may also keep them both in the same repo.

This one is gonna get a bit more complicated but not much.

We are gonna make 2 crates inside our original one and glue them together.

So we had this beauty:

./
 |_Cargo.toml
 |_Cargo.lock
 |_target/
 | |_ ... // we don't care about this, is made in the building process
 |
 |_src/
   |_ lib.rs
   |_ bin/
   |_  |_ framework_that_broke_my_heart.rs
   |_ something/
       |_ mod.rs
       |_ a.rs
       |_ b.rs

Sitting in ./ just next to the "Cargos" we just make two new crates.

$ cargo init --lib db_stuff
$ cargo init ftbmh // framework_that_broke_my_heart, too long,
// too lazy, again, this is an example, name your thing with
// common sense, don't be // funny in a real project, the fun
// will last about 10min, the pain much // more than that.

The argument --lib the only think it does, is instead to make a main.rs makes a lib.rs, by default makes a executable.

So we will get:

./
 |_Cargo.toml
 |_Cargo.lock
 |_target/
 | |_ ...
 |
 |_src/
 |  |_ lib.rs
 |  |_ bin/
 |  |_  |_ framework_that_broke_my_heart.rs
 |  |_ something/
 |      |_ mod.rs
 |      |_ a.rs
 |      |_ b.rs
 |
 | // ^ that's the old part
 |
 |_db_stuff/    // this whole folder is new
 |   |_Cargo.toml
 |   |_src/
 |      |_ lib.rs // <- that's all the --lib does
 |_ftbmh/      // this whole folder is new
     |_Cargo.toml
     |_src/
        |_ main.rs

Now, from the original Cargo.toml we will move the parts as necessary to the new Cargo.toml, for example the dependencies to whoever needs them.

When you are done with that, just clean you good old Cargo.toml and just put this:

[workspace]
members = ["db_stuff", "ftbmh"]

That's it, now the original Cargo.toml doesn't have a [package] or [dependencies] section; the original crate is now a shell.

When you made the 2 crates inside (dn_stuff and ftbmh) cargo saw that you where inside an existing crate with its own git repo so didn't made one for them, your old repo is still good and healthy.

Now remember that you splited your code and probably one part depends on others, in this case ftbmh depends on db_stuff so we have to add that dependency in the ftbmh Cargo.toml file

// ftbmh/Cargo.tom

[package]
// your stuff

[dependencies]
// your dependencies
db_stuff = { path = "../db_stuff" } // as you may know the `..`
// in the path refers to the mother folder of the current one

ftbmh/main.rs already was outside the original crate as you may remember from the last step, so it's all done there and the crate db_stuff was used as an external crate already so everything is the same there too.

Conclusion

We are done. What started as a simple single file project is now a complex crate with 2 workspaces, of course those could be 3 or 100, just rinse and repeat and the same for modules that are the namespaces of Rust.

As you can see, if your code is properly decoupled, the whole process is very unobtrusive, of course is good to have the design planned from the start, but sometimes projects grow more than we thought, they get more complex and is good to have ways to easily adapt it without making a mess, is also good because you don't need to over engineer your solution afraid of a future operations like the one exposed here. You can grow your code organically.

I hope this help someone, there is nothing new here, but I found that it was too disperse in the documentation and books. There is a lot more of it, I didn't talk much about the public/private and what is visible for whom by default, that is very well explained in both The Book and the amazing O'Reilly "Programming Rust", I just tried to make a scaffold to make easy hanging the details later.

Any corrections and suggestion, feel free to let me know specially if something is weirdly written, English is not my native language, this is my best for now.

PSA about systemd

Ghost — Tue, 24 Dec 2019 03:16:15 +0000

Hello everyone,

This is my first post and I hope is a useful one.

For those new to Linux, you may heard about Debian voting on the init system, if you haven't, good for you, you may skip the rest, have a nice day :) .

If you already know what systemd is, you can also can skip the rest and have a nice day too.

How am I doing so far? I already lost 80% of the readers.

I think this post is for the rest of you, you just got your first install or have been blissfuly unaware of all this init system debacle.

TLDR: the whole thing doesn't matter until it does and that will probably be never, so stay blissfuly ignorant of the matter.

For the last 1% of the readers, good for you. Those who are interested in the inner workings of the system have a wonderful journey ahead of you, but beware, there are some unworthy battles out there and I'm afraid this is one of those. These init system discussion lost it's technical value long ago and now is almost a religious one. If you want to learn something about it, avoid all things "Vs" or "best" or "comparisons", just go to the individual descriptions and technical inner workings.

The Linux community can be a wonderfully passionated bunch and as such, can be vicious sometimes, we have to take the bad with the good I guess. So my advice is, don't get involved, these discussion at this point has very little nutritional value.

Have a nice day.

State and Variable in React Hooks

Ghost — Thu, 12 Sep 2019 07:48:01 +0000

I am pretty new to react-hooks and I have yet to discover its real super powers. I want to ask if I am breaking anything if I do the sample code below.


let somevariable= [];

const SomeComponent = () => {
  const [state, setState] = useState({});

  useEffect(()=>{
   fetch('http://insert-api/state')
      .then(response => response.json())
      .then(data => setState({ data }));
  },[])


  useEffect(()=>{
   //update `somevariable` whenever the state changes
   somevariable = state.something
  },[state])


 const clickMe = () => {
   console.log(somevariable)
   //do something to somevariable
 }

  return (
    <button onClick={clickMe}>Click Me </button>
  )
}

Instead of putting somevariablein the state I put it outside to make it kind of global. I did this because when I put somevariable in its own state and set its value in the useEffect it results to endless loop but this one does not, so this is like my workaround. A lot of my functions rely on somevariable that's why it's important for me to know if this approach is alright or not.

PS. I don't know if it's alright to ask this here so please tell me if it's not and I will take it down. Thanks.

The Power of Rules

Ghost — Mon, 19 Aug 2019 11:38:57 +0000

Every organization has their own rules they follow for better workflow. In terms of web development, what are some of the rules you have in your organization? Do you have a boilerplate or some style guide? Or do you set your own rules that you apply in your organization? How powerful are the rules you set that make your development as flawless as it can be? Leave a comment below.

From JavaScript to Swift - Building a List in SwiftUI

Ghost — Thu, 04 Jul 2019 00:00:00 +0000

So you want to build a list with Apple's new declarative UI framework. Maybe you're used to building for the web like I am, and you think, "Let's mock up a data structure and iterate over it to make a list." Pretty straightforward, or so you thought. In JavaScript, you might do something like this:

// Mock data structure
const racers = [
    {
        id: 1,
        name: 'Valentino Rossi',
        team: 'Yamaha'
    },
    {
        id: 2,
        name: 'Marc Márquez',
        team: 'Repsol Honda'
    },
];

// In React
racers.map(racer => (
    <p key={racer.id}>{racer.name} rides with {racer.team}</p>
));

// In ES6
const container = document.querySelector('.container');
racers.map(racer => {
    const item = document.createElement('p');
    item.setAttribute('id', racer.id);
    item.textContent = `${racer.name} rides with ${racer.team}`;
    container.appendChild(item);
});

I thought I could do the same thing with SwiftUI. Define an array of dictionaries and iterate over them using something like SwiftUI's ForEach or List views. In UIKit, List would be roughly equal to UITableView, and from my experience with UITableView, the table wants everything to be set up in a very particular fashion. So approaching cautiously, will List require us to do some extra stuff, or can we just chuck some data in and the world will be well and good? Turns out, there's a bit more setup. This won't work:

import SwiftUI

struct RacerList : View {

      // Mock data structure
    let racers: [[String:String]] = [
        [
            "name": "Valentino Rossi",
            "team": "Yamaha"
        ],
        [
            "name": "Marc Márquez",
            "team": "Repsol Honda"
        ]
    ]

    var body: some View {
        List(racers) { racer in
            if let name: String = racer.name, team: String = racer.team {
                Text("\(name) rides with \(team)")
            }
        }
    }
}

The compiler throws this error: Unable to infer complex closure return type; add explicit type to disambiguate , essentially boiling down to: "Hey, I don't understand what type you're returning." But didn't we say the name and team optionals are strings when we unwrapped them?

As it turns out, the problem isn't with the SwiftUI view code, it's with the data structure. Swift is a strongly typed, protocol-oriented language (bold for my own sake). The data you pass into a List needs to conform to the Identifiable protocol so that it knows how to reference each item.

I like to think about protocols like this: protocols are to class inheritance as GraphQL is to REST. In regular class inheritance in most object-oriented languages, if you want to extend a class, you get all the methods and properties and other stuff from that class in your new sub-class. With protocols, you split up that baggage into different "slices" that you can tell your new classes to conform to. Much like GraphQL, where you tell the backend exactly what you want and what you don't want, protocols allow you to define exactly what you want your sub classes (or structs) to get.

We can implement the Identifiable protocol like this:

import SwiftUI

// Mock data structure
struct Racer: Identifiable {
    var id: Int
    var name: String
    var team: String
}

struct RacerList : View {
    var body: some View {
        let a = Racer(id: 1, name: "Valentino Rossi", team: "Yamaha")
        let b = Racer(id: 2, name: "Marc Márquez", team: "Repsol Honda")
        let racers = [a, b]

        return List(racers) { racer in
            Text("\(racer.name) rides with \(racer.team)")
        }
    }
}

Yay, it works! 🙌 Now if we're to start refactoring this a bit, we can take the data structure, or model as it's known in the iOS world, and put it in a separate directory with all our models. Then, anywhere in our app we define a capital R Racer, the compiler knows we are referencing our model, and hence has detailed information about how it conforms to Identifiable and the type of each property.

Done! This has been another round trip in what may become a loosely associated series of articles about how to do things in Swift coming from JavaScript land. Thanks for reading!

More resources:

Stop Judging Books By Their Covers

Ghost — Fri, 28 Jun 2019 15:38:22 +0000

Many of us (myself included) are guilty of passing judgement on great books because of their jaded or pale or lackluster appearance or accompanying artistic material. Something which all too often prevents us from tapping into the insights which great authors or great content producers provide to us.

In the digital age, the equivalent effect is our perception of stock photos, the images which accompany the articles that publications like the ones found on Medium produce.

How often have we decided to pass up the opportunity to read something interesting because of a badly selected stock photo, or scrolled through a Medium article hurryingly as we pass judgement on the content of the article.

But do we ever stop to think, to think about the awesome content we are missing when we make value judgements about articles or books, or podcasts, or even people. I’d argue that the answer to that question is nay.

Why did I choose to write an entire post on this topic? The answer can be found in the pages of a book I recently purchased by Henry Allison, on the topic of the Transcendental Aesthetic.

Allison, goes to painstaking lengths (through the use of complex metaphysical arguments) to attempt to prove to its reader that the reasoning which German Philosopher, Kant used in his various intertextual critiques had something quite important to say on the topic, and the reasoning as to why human beings make value judgements about abstract concepts such as beauty and appeal.

In that sense, beauty is very much relative. What I find beautiful, you may not find beautiful and what I hold dear to my heart as something which retains aesthetic value, you may view through a lens of normality.

This may include books, and their covers. That will always be the case unfortunately, so I guess this article is just a polite means of drawing our attention to the beauty within the pages of your next read.

Happy reading!

Am I using too many Coding sites?

Ghost — Thu, 20 Jun 2019 00:00:22 +0000

Hi guys,

After some advice. Wanted to start coding for awhile now with the aim to change careers too. And I also intend on starting a second degree in the autumn via distance learning. What I am worried about is that I keep flittering about with different websites that will teach me to “code”?

Basically got a list of;

SoloLearn App.
Udemy.com Courses
Dev.to
CodeAcademy
The Odin Project
freeCodeCamp
w3schools.com
Scrimba
Pluralsight

Which would you all recommend? I want to focus. But I also won’t the best one that will help me get a job in the industry.

Managing colors with extensions in Swift

Ghost — Sun, 12 May 2019 00:00:00 +0000

As a full-time developer on the web and part-time dabbler in the world of iOS development, I recently tried to create some color variables to use throughout a project in a single location. In most web development projects, you might put these inside a utils folder and import them wherever they are needed:

Define color variable:

// utils/colors.js

export const dark = '#151951' // Default for all text

Use the variable:

// components/container.js

import { dark } from '../utils/colors'

const Container = () => {
    return <p style=`color: ${dark}`></p>
}

export default Container

But in iOS development with Swift, there’s a problem with this. Unlike on the web, you don’t explicitly declare what you are importing and exporting in each file. Instead, methods of classes just magically become available throughout the project. While convenient, how will others reading your code know where the methods are coming from?

We could use a Swift protocol and namespace all the utils in the same class, or do something a bit simpler which I prefer: prepend an _ before all extensions so we know they’re custom utility functions. The same example above would then look like this, using extensions in Swift:

The usage of hex values for colors in iOS development requires some extra computation with UIColor because Apple doesn’t accept hex values directly. See dozens of different implementations of this on StackOverflow. The following approach is borrowed from Jared Davidson, and the emoji logging idea from Andyy Hope’s Pretty in Print series.

Define color variable:

// Colors.swift

import UIKit

extension UIColor {

    // Defined colors
  static let _dark = UIColor().hex("#151951")

  func hex(_ hex: String) -> UIColor {

    // Clean string
    var hexString = hex.trimmingCharacters(in: .whitespacesAndNewlines).uppercased()

    // Remove hash
    if hexString.hasPrefix("#") {
      hexString.remove(at: hexString.startIndex)
    }

    // Log warning if hex value is not 6 characters
    if hexString.count != 6 {
      print("⚠️ Hex value #\(hexString) is not 6 characters.
      Please enter a value with 6 characters.")
      return UIColor.white
    }

    var rgb: UInt32 = 0
    Scanner(string: hexString).scanHexInt32(&rgb)

    return UIColor.init(
      red: CGFloat((rgb & 0xFF0000) >> 16) / 255.0,
      green: CGFloat((rgb & 0x00FF00) >> 8) / 255.0,
      blue: CGFloat(rgb & 0x0000FF) / 255.0,
      alpha: 1.0
    )
  }
}

Use the color variable:

// CustomLabel.swift

import UIKit

class CustomLabel: UILabel {
  required init?(coder aDecoder: NSCoder) {
    super.init(coder: aDecoder)
    self.textColor = UIColor._dark
  }
}

As I’m rapidly realizing, things you can do simply on the web with JavaScript don’t often come for free in iOS with Swift. This may be due to the relative newness of the language, particular design choices made by the architects, or a mix of both.

While I know it’s not exactly helpful to apply web thinking to a native iOS context, I find it useful to compare and contrast implementations as I’m learning to write more idiomatic Swift. Hopefully, I’ll come out a better software developer at the end of the day.

Cheers! 🍻

We're all internet hoarders

Ghost — Thu, 09 May 2019 00:00:00 +0000

Over the past few years I’ve moved around a lot, living in Los Angeles, Seoul, Beijing and now Singapore. Over the course of these moves I pared down my belongings, so now everything fits in just two large pieces of luggage.

But on the internet, this is so much more difficult to do. Most of us have more than a few suitcases worth of accounts and user data floating around out there. More so, even if we want to toss out some of these things, we usually can’t do it quickly or easily. For each account,

Log in (~30 seconds)
Reset password? (~1-2 minutes)
Export user data? (~1-2 minutes)
Delete account (~1-2 minutes)

That’s 5 minutes per account. Now multiply that by all your accounts, of which I have, maybe 20 or 25. Now imagine you get stuck in a loop trying to reset a password or retrieve an old email address in a janky auth flow (Microsoft, looking at you).

🤯 If only we could just rm -rf accounts

But the saga continues. Besides closing down old accounts, what about changing all your passwords to unique, secure ones and storing them in a password manager? I’ve been down that road already. Estimate many more days or weeks.

The point is, It’s really hard to have just two suitcases worth of internet stuff because it lives in so many guarded places. I’m a fan of new projects emerging from this line of thinking like Solid, but it may be some time before every user is savvy enough to have something like their own personal “pod” or cloud.

That being said, I’ve been thinking about a few actionable targets we can observe as developers that can help new apps avoid adding to this unwelcome trend:

Do not require authentication, or if absolutely necessary, require only an email address.
Store data locally or in a cloud already owned by the users.
If data is stored remotely, make user data export and deletion as readily accessible as possible.

If all goes well, I plan on implementing these ideas in the side project I’m working on now. As for the rest of the apps out there that we depend on daily, the only way is to painstakingly reduce our dependency until cleaner alternatives are built.

Cheers! 🍻

Does contributing to open-source companies increase the chance of a job there?

Ghost — Thu, 03 Jan 2019 20:50:58 +0000

Hello I'm coming from HN
As the title says, Does contributing to open-source companies such as:

Gitlab
Ghost
Discourse
Edx
Google(Angular, Flutter, Tenserflow)
Facebook(React, React Native, Jest)

Increases (Dramatically) Chances of getting a job at said companies? to a point where said companies reach out to the contributor?

Theme your Expo app with Redux and React Navigation

Ghost — Sun, 23 Dec 2018 13:15:22 +0000

Recently whilst developing a React Native app (with Expo), I built a simple tab navigator using React Navigation library. I wanted to theme the app so that the header would change colour depending on which page you’re on. For example on the primary page it would be red and on the secondary page, when you change tabs, the header would become blue.

I ended up being able to do it using Redux. In this article, I will show you how you can theme your Expo app using Redux with React Navigation.

P.S. This article is written in British English however, the code is written using American English to make it more consistent (colour vs color).

React Navigation

Is a library that helps you simplify app navigation. The main reason for using this library is because it’s written purely in JavaScript so no native code (Swift/Android) is required to make it work. Also, it’s the recommended navigation library for Expo.

Redux

Redux is used to manage global state across a React app, it can actually be used with both React and React Native. Of course, in this example, we will be using Redux with a React Native app.

Redux Store, from https://css-tricks.com/learning-react-redux/

The diagram above explains pretty well why you may need to use Redux. Passing state can be tricky in more complicated React Native apps, with lots of components and sub-components. Using redux we can change the state in one component and Redux will update the state in all the other components.

There are many great tutorials about Redux, I particularly liked this one. Here is brief summary how Redux will work with this app.

Redux sets the initial (state) colour to red
Change tabs from main to the secondary page
This dispatches an action to the Redux store (action is called toggleTheme)
The store then calls a reducer
The reducer (also called toggleTheme) updates the old state to a new state, it changes the colour from red to blue
Redux updates the state in all the components

Here is a GIF that might help clear up how it work.

Redux Flow, from http://slides.com/jenyaterpil/redux-from-twitter-hype-to-production#

Prerequisite

An Expo/React Native app
An Android emulator/device to test on
Install the following dependencies

"react-navigation": "^2.18.0",
"react-redux": "^5.1.1",
"redux": "^4.0.1",

Solution

Now to the interesting part of this article let’s take a look at the code.

Structure

The project structure will look like this

├── src
│ ├── actions
│ ├── components
│ ├── containers
│ ├── reducers
│ ├── screens
│ ├── store
| └── themes
├── package.json
├── App.js

themes

themes/index.js

Here we define our two colours that will be used as themes, red and blue. I have given each colour a name because it makes the toggle logic easier to follow.

reducers

reducers/Theme.js

A reducer is a pure function which takes some state and returns a new state. In this example it gets passed the current theme colour and swaps it to the new theme colour.

In this example if the action is TOGGLE_THEME, we get the colour name from the payload and using a switch statement we swap the colours over. So if the current colour is red we update the state (colorData) to be blue.

reducers/index.js

Here we combine all of our reducers, in this example, we are only using the one reducer but if we had multiple reducers, The combineReducers function to would be necessary to combine them together. In this example we can simply add new reducers to the function as and when we need them.

actions

actions/actionTypes.js

This file defines all the actions we can dispatch to our store. In this example, we only need one action to toggle our theme.

actions/index.js

In this file, we define our actions, so here we have a single action toggleTheme, which takes a theme as input and passes it as our payload, hence to access the name of the colour we use action.payload.name in our reducer.

store

store/index.js

The Redux store is used to store the current state for our app, we have to link our store with our reducers we can do this using the createStore function and import the reducers from reducers/index.js.

App.js

This acts as the main file for our app, to use Redux with our app we must wrap around Provider tags and set the store props to our store/index.js file. The contains the logic for our two screens and the tab navigator.

components

components/CustomTabNavigator.js

Here is where we use react navigation to create our tab navigator. We define two screens called A and B, each screen has a different tab colour, red for A and blue for B. The main part of this file is the following

tabBarOnPress: ({ defaultHandler }) => {
 store.dispatch(toggleTheme(COLORS.red));
 defaultHandler();
},

On tab change (from A -> B), we detect the tab press and dispatch the toggleTheme action to the Redux store. So when we change tabs from A -> B the colour in the store will change from Red -> Blue and vice versa for B -> A.

One other thing to note is the tab colour is set using the following function. The colour is passed by the tabBarOptions.

const commonTabOptions = color => ({
 activeTintColor: 'white',
 pressColor: '#fff',
 inactiveTintColor: '#ddd',
 style: {
 backgroundColor: color,
 },
});

tabBarOptions: commonTabOptions(COLORS.red.hexCode)

components/ToggleTheme.js

This file does most of the heavy lifting for this app, this is where most of the logic sits. So, first of all, we have a button, which calls toggleTheme on a press of the and passes the current colour (state) as an argument.

<Button
 title="Toggle Color"
 color={this.props.color.hexCode}
 onPress={() => this.props.toggleTheme(this.props.color)}
/>

The colour of the button is also using the current (state) colour, so in this case, it will start off as red, this.props.color. We can access the current state using this.props.

const mapStateToProps = state => ({
 color: state.Theme.colorData,
});

This function is used to map the Redux store to the state of this component. We map state.Theme.colorData, where Theme is the name of our reducer and colorData is the item name. In this example, we've mapped the current colorData to color props in this component.

const mapDispatchToProps = dispatch => ({
 toggleTheme: color => dispatch(toggleTheme(color)),
});

This function maps a function to an action (and dispatches it), in this example when the toggleTheme function is called in the component it will dispatch the toggleTheme action to redux. So when the button is pressed it will dispatch an action to toggle the theme.

PageA

screens/PageA.js

This is an example of one of our screens, it’s very simple just the page name and component.

Example

The app running on an Android emulator.

Here is an example of the app running, as you can see there are two ways we can toggle the theme. We could use the button click, or change tabs.

Extra Task: If you want some practice, currently this won’t detect a swipe action to change tabs look at how you can do this. An example of it working can be found here.