DEV Community: Ariel Bogdziewicz

Git config user.email for repositories in subdirectory

Ariel Bogdziewicz — Sat, 26 Sep 2020 00:06:28 +0000

Quick hint for developers working on source code from different Git accounts having different e-mails for them. Let say we develop our own projects and we support development for two other companies. Our folder structure could look like

~/.gitconfig
~/PersonalProjects/
~/CompanyAbc/.gitconfig
~/CompanyMno/.gitconfig

Of course we have configured default config as follows

user@mymac ~/ $ git config user.name "Firstname Lastname"
user@mymac ~/ $ git config user.email "user@myprivatebox.com"
user@mymac ~/ $ git config push.default simple
user@mymac ~/ $ git config core.editor emacs

We want different e-mails by default for all repositories in these directories without configuring this manually with command

user@mymac ~/CompanyAbc/website-repo (master) $ git config user.email "user@company-abc.com"

every time when wy clone new repository.

Solution

Main ~/.gitconfig file should look like

[user]
        name = Firstname Lastname
        email = user@myprivatebox.com
[push]
        default = simple
[core]
        editor = emacs
[includeIf "gitdir:~/CompanyAbc/"]
        path = ~/CompanyAbc/.gitconfig
[includeIf "gitdir:~/CompanyMno/"]
        path = ~/CompanyMno/.gitconfig

Set custom e-mail address in ~/CompanyAbc/.gitconfig

[user]
        email = user@company-abc.com

You can repeat this for other configurations like ~/CompanyMno/.gitconfig too.

Verification

Please execute command to verify new settings

user@mymac ~/CompanyAbc/some-repo/ (master) $ git config user.email

It should throw out something like

user@company-abc.com

Good luck with coding!

How to make Swift's [String: Any] decodable?

Ariel Bogdziewicz — Tue, 08 Sep 2020 15:30:50 +0000

Do you need to decode your JSON to [String: Any]? Here is how you can do this.

Requirements

Answer is that you cannot do this using Any type. You need specify something more concrete than Any.

Dictionary is automatically decodable if its elements are decodable. Type Any is not decodable.

However if you are looking for the answer it means that you actually have some kind of JSON which needs to be handled somehow. The topic is also related to array like [Any].

Solution

You need to specify finite number of possible values of your Any type. For example we expect that there are two different structures like following:

struct Payload: Codable {
    let id: String
    let eventName: String
    let metadata: [Metadata]
}

struct Metadata: Codable {
    let name: String?
    let price: Double?
    let rating: Int?
}

But of course you cannot do

let decodedData = try JSONDecoder().decode([String: Any].self, from: json.data(using: .utf8)!)

because there is used type Any.

First of all we need to figure out how JSON for this dictionary possibly looks like. It would be sth like this:

{
    "keyNumber1": {
        "type": "payload",
        "data": {
            "id": "someId1",
            "eventName": "Event Name 1",
            "metadata": []
        }
    },
    "keyNumber2": {
        "type": "metadata",
        "data": {
            "name": "Metadata Name",
            "price": 123.4,
            "rating": 100
        }
    }
}

Then it's simple because you need to define enum instead of your Any type like follows:

enum DataType: String, Codable {
    case payload
    case metadata
}

enum MyValue: Decodable {
    case payload(_ payload: Payload)
    case metadata(_ metadata: Metadata)

    private enum CodingKeys: String, CodingKey {
        case `type`
        case `data`
    }

    init(from decoder: Decoder) throws {
        let map = try decoder.container(keyedBy: CodingKeys.self)
        let dataType = try map.decode(DataType.self, forKey: .type)
        switch dataType {
        case .payload:
            self = .payload(try map.decode(Payload.self, forKey: .data))
        case .metadata:
            self = .metadata(try map.decode(Metadata.self, forKey: .data))
        }
    }
}

And decode JSON using following code:

let decodedData = try JSONDecoder().decode([String: MyValue].self, from: json.data(using: .utf8)!)

Full Playground code:

Total failure of Xcode Storyboards

Ariel Bogdziewicz — Sun, 06 Sep 2020 23:41:59 +0000

There is no benefit to using Xcode Storyboards at all! Not even one! This article presents the complete list of reasons. But first, have some lemon balm or something else to calm you down before reading especially when you like this tool.

When did it happen? 🤦🏼‍♂️

I couldn't write my first post about something else after long years of development an iOS applications. How could I expect that it's so terrible when iOS SDK 5.0 brought wonderful ARC (automatic reference counter) and Storyboards to improve our performance at work. Everyone started using it to be more modern and write less code 🤩 The best code is the one that doesn't exist. Sounds right?

No way ✋🏻

It took more than two years to show all bad consequences of using this tool. But Storyboards became a real enemy when product owner requested changes using kind words:

Please change fonts, colors and margins in all views but only for one brand. We are going to rebrand the app.

Change what?! 🧐 😱

Full list of faults

Full list of cons is long so description for each point is short and full educational explanation will be delivered in other articles of the serie Bad Xcode Storyboards. Points are ordered starting from the most annoying from my perspective of experience with Storyboards based on three commercial projects.

1. Weak reusability

Reusability is almost non-existence without additional effort. It's related to reusability of view controllers and single views. Good architecture assumes that you can easily customise the app. That you can easily change fonts, colors, margins or add another theme for new brand just by changing a few lines of your code. It's true that you can use Storyboard references to use external view controller from another Storyboard file or set custom class for views like labels. Would you like to do it every time when creating every single label, button or switch? Base classes for all basic UI components are very helpful to easily configure your UI. However it's extremely not comfortable when using Storyboards.

2. Storyboards are set of hardcoded and not reusable values

How many times did you report in code review that someone needs to use constant for hardcoded integer value? Because you know bad consequences of it. Hardcoded value has no meaning and no association with other occurrences. Guess what? All dimensions, colors, fonts are hardcoded in Storyboards and nobody cares. It's very similar to previous point but this point is related to reusability of single scalar values instead of view or view controllers. Ok, so lets change now fonts and margins in views from all our 75 view controllers implemented using Storyboards 💣

3. Post-configuration in source code

You need to write code for views anyway even when using Storyboards. Not everything is predicted to be configured using Storyboards and these files can't read your global configurations for your views. So very often it ends with post-configuration in methods like viewDidLoad. Then it's hard to keep consistency of the code because some properties are set in Storyboards and others in source code. Wouldn't be it better to keep configuration of views only in one location and format?

4. Broken preview

In most cases preview shows nothing useful. You can of course use @IBDesignable and @IBInspectable just to maintain preview in Storyboards 😎 Why not if someone has a lot of time and power? 💪🏻 But wait, how to edit views which are located under another one or out of the bounds? Where is this transparent view?! Where are shadows, borders and rounded corners? 🤣 It's the only candidate to defend Storyboards but this failed too. Hopefully live preview introduced for SwiftUI solves this problem much better.

5. Storyboards fail at runtime

Some properties are not validated in compilation time. So in case of forgotten identifiers of view controllers, cells, or other views you will get exception at runtime. It means that you can miss that and release to the end user when tests don't catch the issue. It's very sensitive for stupid mistakes like typos. So when you write code like this

let storyboard = UIStoryboard(name: "StorybardName", bundle: Bundle.main)
let viewController = storyboard.instantiateViewController(withIdentifier: "MyViewController") as! MyViewController

you use two string identifiers like "StorybardName" and "MyViewController" which are not validated in compilation time. It's much simpler to do just

let viewController = MyViewController()

and it's not bug prone.

6. Forgotten `@IBOutlet` and `@IBAction`

More over there are things which are not validated even in runtime like forgotten assignments for @IBOutlet or @IBAction. It's more related to Objective-C where you can call method or use properties on nil without crash. That's why it's better to use

@IBoutlet weak var myView: UIView!

instead of

@IBOutlet weak var myView: UIView?

in Swift. However it's still only runtime validation. But you can do nothing to detect missing @IBAction automatically. The same issue is related to forgotten class names for your custom views. All these worries take your time and bring lower quality of the end result if you don't catch your mistake yourself.

7. Merge conflicts

Storyboards are unpredictable XML files. Every saving can change order of XML elements or attributes randomly without special reason. Would you like write views in your team? Assign maximum one developer per Storyboard file.

8. Code reviews are almost impossible

It's very difficult to make code review for Storyboard files. These XML-s files are based on some elements and attributes which are unkown for most of developers. More over it's extremely hard to imagine what they present when reading its content.

9. Storyboards are slow

Xcode has troubles with performance when Storyboard file is opened even if there is only one view controller. It shows beach death ball very often when it freezes ⛱ I need to admit that it has been improved last time however files with source code are always faster 🚀

10. Storyboards are buggy

Haven't you got troubles with strange dimensions converted from 50.0 to 49.9999? Or changed frames without your awareness? Added some strange XML elements at the end after each save? Troubles to align views correctly especially when changing device for preview? It happened to me many times.

11. Not friendly translations

I hate these strange identifiers with unreadable format for humans like

/* Class = "UILabel"; text = "English text in Storyboard"; ObjectID = "LSm-a6-m9b"; */
"LSm-a6-m9b.text" = "Polish translation";

It would be much simpler to keep all translations in common file Localizable.strings to make them reusable for all views like

"English text" = "Polish translation";

and use in source code function like

func localizedString(_ text: String) -> String {
    return NSLocalizedString(string, comment: "")
}

to gain access to translations. More over it would be even possible to introduce validation in compilation time introducing enum for translations to have full control over translations in our project that we could not miss any translation.

12. Hard debugging of constraints

Sorry but this tree of constraints is almost not manageable. Better is when you select one particular view to see its constraints. However editing of properties for constraints means mouse acrobatics on the desk and it's hard to make easy overview of settings. And what about forgotten @IBOutlet for constraint? That's the pain of lost day 🤕

13. Segues paradox

That's difficult part to explain. However existence of segues suggest that we should make Storyboards as big as possible that our story could be complete, that you could see all associations between view controllers visually in this very big and beautiful Storyboard.

On the other hand we know what are consequences of using very big Storyboards. They are difficult to maintain and editor slowdowns proportionally to the number of view controllers in your story. Developers very often decide to keep Storyboards with only a few view controllers or even only one using partially segues and partially using transitions between view controllers in source code. It makes your project inconsistent.

So purpose of Segues seems to be irrational.

14. Mouse clicking

Day with Storyboards serves you terrible pain in your hand because of mouse clicking. Bloodshot eyes from straining to look for another text field or checkbox. Have I really set constraint to safe area? Or was it margin? Lets check again... Oh no, which tab of properties should I switch to again? Jumping between Storyboard and source code is also fun. But hey, I'm not wasting time for writing difficult source code.

15. Context switching

Storyboards serve you not only pain in hands or eyes. Your brain may explode 🤯 because of switching between source code and Storyboards having content with different kind of presentation and nature. So brain needs to switch from source code mode to tracking visual components of Storyboards and vice versa when going back. And you need to remember what you actually was doing in previous context. Context switching takes time and makes you exhausted 😵

16. Extremely difficult refactoring

Haven't you tried to reorganise view hierarchy of your Storyboard's view controllers? It better to delete all and build it from scratch when changes are more revolutionary. Otherwise you will lost yourself in the middle of your work.

17. Storyboards require additional maintaining

Storyboards don't make job for you. If you don't want to write source code then you must click this with mouse. But Storyboards are one additional more layer which brings bugs you can't fix, new therms like segues or @IBOutlet/@IBAction you need to know and remember about. And even more you can spend extra time implementing and testing @IBDesignable/@IBInspectable or custom segues. So you need to deal with these things but they wouldn't be needed if you were not using Storyboards. So it's extra layer of worry.

There is some good about Storyboards

No, there is not!

Final result

Programmatic views 17 : 0 Xcode Storyboards

Horrible Storyboards

I've found similar article Horrible Storyboards. It mentions about another issues which I haven't experienced yet like:

Storyboards don't let you change the type of special view controllers

Storyboards add two extra liabilities to your project

Storyboards don't allow you to add a subview to a UIImageView

Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s

Storyboards have a higher risk of breaking backwards compatibility

What are alternatives?

It appears that writing views programmatically is not easy too. Apple didn't provide easy in use classes and methods to write views easily. At least notation could be shorter however concept of constraints itself is quite good in UIKit. That's why people invented a lot of DSL (domain-specific language) libraries like the most popular SnapKit, tricky Carthography or super concise Stevia. I invented my own DSL AutoLayout library LayoutExtension which is now in early version however I use it in one commercial project with full success.

DEV Community: Ariel Bogdziewicz

Git config user.email for repositories in subdirectory

Solution

Verification

How to make Swift's [String: Any] decodable?

Requirements

Solution

Total failure of Xcode Storyboards

When did it happen? 🤦🏼‍♂️

No way ✋🏻

Full list of faults

1. Weak reusability

2. Storyboards are set of hardcoded and not reusable values

3. Post-configuration in source code

4. Broken preview

5. Storyboards fail at runtime

6. Forgotten @IBOutlet and @IBAction

7. Merge conflicts

8. Code reviews are almost impossible

9. Storyboards are slow

10. Storyboards are buggy

11. Not friendly translations

12. Hard debugging of constraints

13. Segues paradox

14. Mouse clicking

15. Context switching

16. Extremely difficult refactoring

17. Storyboards require additional maintaining

There is some good about Storyboards

Final result

Horrible Storyboards

What are alternatives?

6. Forgotten `@IBOutlet` and `@IBAction`