How to achieve ARM cross-compilation on macOS

Kai Sasaki — Wed, 24 Jun 2020 06:58:54 +0000

This article originally comes from lewuathe.com. Please visit there too if you find this interesting.

Cross-compilation is occasionally troublesome. It often requires us to install additional toolchain to get it done.

Now, I found I needed to compile my source code for the Arm architecture machine for Mbed application. I do not have any idea how to install the toolchain for Arm compilation. Thus this is the post to describe the fastest way to prepare the toolchain for the cross-compilation for Arm.

Xcode Compiler

Please ensure to install Xcode first. Xcode contains the first compiler sets, such as clang.

$ xcode-select --install

Arm Toolchains from Homebrew

You can install Arm GCC toolchains by using Homebrew. There are two options.

There is no difference between these two distributions. They use precisely the same package internally. You can use whichever you want.
For my Mbed application, I choose the second one.

$ brew tap ArmMbed/homebrew-formulae
$ brew install arm-none-eabi-gcc

You should be able to find the compiler eventually. The following tools are installed in the local machine.

$ arm-none-eabi-gcc
$ arm-none-eabi-g++
...

It looks like they are GCC for Arm architecture. I believe it is the easiest way to prepare the Arm build toolchains in macOS platform.

Thanks

A Reader to Writer

Kai Sasaki — Mon, 22 Jun 2020 00:43:21 +0000

For a long time, I was an enthusiastic reader of dev.to. The platform has provided me a lot of inspiring articles to accelerate my skill and knowledge around various kinds of technologies as a developer. Now, I decided to contribute my own experience by writing posts here as others did. I hope my writing will help someone others in the field develop their own skills as I did in the dev.to in the past several years.

Thanks and hello!

Why we should avoid default_scope in Rails

Kai Sasaki — Mon, 22 Jun 2020 00:11:53 +0000

This article originally comes from lewuathe.com. Please visit here as well if you enjoy it.

ActiveRecord in Rails provides a way called scope to keep the readability along with encapsulating the detail of the business logic in the model class. It enables us to add a more intuitive interface to the model so that we can quickly call the scoped method without caring about the complicated underlying implementation. This also contributes to achieving the well-known good practice in the MVC model, "Fat Model, Skinny Controller". It shows us the clear guidance saying, "We should not write non-response related logic in the controller". If you are writing a complicated logic that is not directly related to the HTTP response construction response, that should go to the model, not controller. scope methods are helpful to materialize this goal.

What is `default_scope`?

As part of the scope feature, ActiveModel has a default_scope which defines the scope method applied to all queries on the model. Let's say we have a User model as follows.

class User < ActiveRecord::Base
end

User.all returns all users as it states. But what if you want to get the users excluding all hidden users. The following code will return the results as you expected.

User.where(hidden: false)

But default_scope will provide a more convincing manner.

class User < ActiveRecord::Base
  default_scope { where(hidden: false) }
end

This default_scope is always applied to the model query. In other words, you do not need to specify the query explicitly anymore.

User.all # It will return the visible users, excluding hidden ones.

That is good. You do not need to specify the same where conditions many times. default_scope automatically creates the basis of all queries.

Practically, default_scope is often not recommended in Rails.

Implicit Behavior Change

Based on my experience, the biggest problem of the default_scope is applied implicitly. If the writer of the default_scope is different from the model user, the behavior must look weird. Model users will see a query they do not write unexpectedly. Implicit behavior change is generally anti-pattern. (In Scala, even the compiler shows the warning for the implicit type conversion.).

In my case, I have developed one API using the model class, which is derived from the original web application. Since the data source is shared with them, it is useful to share the model class too. But it brings unexpected pitfall caused by default_scope. At some time, another developer introduced the following default_scope.

class OriginalClass < ActiveRecord::Base
  default_scope { select(all_columns) }
end

An application I have developed is using the class. What I want here are only c1, c2, and c3. Returning all columns can cause the problem.

OrignalClass.where("c1 = xxx").select("c1, c2, c3")

As you imagine, introducing the default_scope here makes it happen. Without any notice, all columns are returned because I do not know the change around the default behavior of the OriginalClass.

Implicit behavior change is always requiring intensive care. All developers touching the codebase and related repository need to be careful of the transformation of the behavior. But we must not expect all members to do so. It's unrealistic.

Use `scope`, not `default_scope`

Here is a simple answer. Use scope, not default_scope. What we want to do was completely achieved by scope. There was no special reason to use default_scope.

class OriginalClass < ActiveRecord::Base
  scope, get_all_columns -> { select(all_columns) }
end

Using scope does not break any user codebase implicitly. If a user wants to make use of this new scope, call it explicitly. Of course, default_scope can reduce the amount of code you need to write in terms of the number of characters. But the damage and maintenance cost will surpass the benefit obtained by the default_scope. Simply obeying the following guidance will lead you to keep the Rails code clean and more maintainable.

Use scope, not default_scope

Thanks for reading!

DEV Community: Kai Sasaki

How to achieve ARM cross-compilation on macOS

Xcode Compiler

Arm Toolchains from Homebrew

A Reader to Writer

Why we should avoid default_scope in Rails

What is `default_scope`?

Implicit Behavior Change

Use `scope`, not `default_scope`

References

DEV Community: Kai Sasaki

How to achieve ARM cross-compilation on macOS

Xcode Compiler

Arm Toolchains from Homebrew

A Reader to Writer

Why we should avoid default_scope in Rails

What is default_scope?

Implicit Behavior Change

Use scope, not default_scope

References

What is `default_scope`?

Use `scope`, not `default_scope`