新着記事

TORICO が漫画アプリ開発に Flutter を採用した事例の紹介

当社 TORICO は、モバイルアプリの開発に Flutter を採用しています。

この記事では、2023年1月現在の、TORICO での Flutter 開発事例を紹介します。

TORICO が モバイルアプリ開発に Flutter を採用する理由

共通のコードで iOS と Android に両対応できる点と、Dart 言語での開発の体験が良いことが Flutter を採用している理由です。

私の主観が入りますが、Dart 言語については、概ね TypeScript での開発体験と似ていますが、TypeScript が引きずっている JavaScript が持つ特徴的な挙動(this の挙動、null, undefinedの扱い、Date オブジェクト等)が無く、書きやすい言語だと感じます。

Dart はライブラリの開発もしやすく、パッケージマネージャ(pub)も標準で搭載されていますので、有志の型が開発されているライブラリの導入も容易です。

加えて、Flutter は Windows や Mac 等のデスクトップアプリにも対応できます。
開発体験は Electron を使った場合と似ていますが、Electron に比べて生成プログラムのサイズを小さく保てますので、配布に適していると思います。

TORICO では、社内で使う小規模なツールの開発に Flutter を使う場合があります。

TORICO で Flutter を採用しているアプリ

スキマ

スキマ | 全巻無料漫画が32,000冊読み放題!

スキマは漫画を無料で読めるサービスです。

モバイルアプリ版は Flutter で開発しており、iOS Android 両プラットフォームで配信しています。

スキマのサービスは、2015年に開発を開始し、4月28日よりサービスを開始しました。
開発当初は、iOS は Objective-C、Android は Java で開発していましたが、2019年に Flutter に切り替えています。

当初の Flutter のバージョンは 1.3 ぐらいだったと思います。

当時は状態管理やルーティングの有用なライブラリは少なく、FutureBuilder などをそのまま使う場面が多くありました。

Flutter のバージョンアップには積極的に対応し、現在は Flutter 2の最新版で開発を行っています。

2023年1月現在の技術スタックは、 zenn の 0maru の記事を参考にしてください。

約3年間Flutter で開発してきてのあれやこれや

スキマや、後述の漫画全巻ドットコム等で使われている、 Flutter での Twitter のログインを提供するパッケージ twitter_login は、 0maru の開発によるものです。

スキマは 広告SDKを多く扱うため、Swift や Kotlin の開発分量も少なくありませんが、広告 SDK のコントロールは Flutter 上から行えるようになっており、Firebase と連携してリモートで調整することができます。

スキマのモバイルアプリをダウンロード: iOS | Android

漫画全巻ドットコム

漫画全巻ドットコム | コミックセット通販

漫画全巻ドットコムは、漫画の全巻販売に特化したECサイトです。

モバイルアプリも提供しており、 Flutter で開発し、iOS Android 両プラットフォームで配信しています。

アプリのリリースは 2021年7月27日より行っており、リリース初期から Flutter を使っています。

リリース時期の技術スタックは、 zenn の 0maru の記事に書かれていますのでご覧ください。

Flutter でECアプリを新規開発してみて

漫画全巻ドットコムのモバイルアプリをダウンロード: iOS | Android

漫画全巻ドットコム MZ Reader

漫画全巻ドットコムは、紙のコミックの全巻セット販売だけでなく、電子書籍も販売しています。

MZ Reader は、漫画全巻ドットコムで購入した電子書籍を読むためのアプリです。

電子書籍サービスは 2012年11月に開始しており、当時は iOS は Objective-C、Android は Java で開発を行っており、Windows 版も提供していました。

電子書籍ビューアは 2020年10月にリニューアルを行い、フレームワークに Flutter を採用しています。リニューアル時点ではアプリの評価が低かったのですが、体験の向上を目的としたブラッシュアップを行い、アプリの評価を大きく改善することができました。

新入社員が入社後数ヶ月でコミックリーダーアプリのレビュースコアを 1.4 → 4.7 に改善した話

電子書籍のダウンロードには、Dio と Flutter Downloader を場面により使い分けています。

2023年1月現在、Flutter2 でリリースをしています。

MZ Reader をダウンロード: iOS | Android

マンガ展

マンガ展 | まんが作品の原画展・イラスト展やサイン会などのイベント情報掲載

マンガ展は、マンガの作家さんとのイベントを提供するプロジェクトです。

現在、東京の池袋と渋谷(Magnet By Shibuya 109内)、大阪の谷町六丁目、名古屋の栄のオアシス21内、台湾の台北101の近くに店舗を運営しており、イベントを開催しています。

国内の各店舗の地図 | マンガ展台湾の地図 

物品の購入や会場での来場スタンプが獲得できるモバイルアプリを公開しています。

マンガ展のアプリは 2019年1月からリリースしており、Flutter を採用したアプリの中では一番早い時期となります。

Flutter のバージョンは v0.10 あたりから使い始めたように思います。マンガ展アプリのリリース直前で、Flutter v1.0 が公開されたタイミングだったように記憶しています。

現在は Flutter2 対応で Null Safety になり、状態管理は RiverPod を使っています。

マンガ展のモバイルアプリをダウンロード: iOS | Android

Andorid レジ

Sunmi 社の T2s や T2 mini で動作するレジを Flutter で開発しています。

Sunmi 社のレシートプリンタのバインディングライブラリの sunmi_printer_plus  内の、T2 mini の LCD のバインディングを ytyng が開発しています。

T2s は、2つのディスプレイを持つ Android 端末です。presentation_displays パッケージを使うことで、サブディスプレイにも Flutter のウィジェットを表示することができます。

状態管理は Riverpod, hooks_riverpod を使っています。

デスクトップツール

Windows上で動作する、漫画全巻ドットコムの CMS 連携ツールを Flutter で開発しています。

漫画全巻ドットコムでは、一部のキャンペーンページのコンテンツデータをデータベースに保存しています。

コンテンツデータは非エンジニアの運用スタッフが作成するのですが、Web フォーム上での作成は体験が悪いので、Windows 上の VSCode と連携して作成できるツールを Flutter で作っています。

Flutter を採用している理由は、社内の開発者は全員 Mac を使っているため、Windows での使用を要件としたクロスプラットフォーム開発となると使える技術が絞られることと、その中で 実行バイナリのサイズが小さく、別途ランタイムライブラリも必要無く、動作が安定しているためです。

最後に

株式会社TORICO では、Flutter で自社サービスを開発する技術者を募集しています。

業務内容として Flutter 100% ではなく、AWS、MySQL、ElasticSearch(OpenSearch)、Python Django 等サーバサイド開発も扱っていただきます。応募フォームからの連絡をお待ちしています。

https://www.torico-corp.com/recruit/

当社プロダクトにおける、nuxt2→nuxt3 への移行時の記録

2022年11月16日、Nuxt3 が正式リリースされました。

当社でサービスしているプロダクトの1つを、Nuxt2 から Nuxt3 に書き換えましたので、変更した実施内容を書きます。

Nuxt2 から Nuxt3 への変更点

概要としては、 Zennの下記記事が参考になります。

祝・正式リリース!5つのテーマで理解する Nuxt3 の魅力

具体的な変更点や使い方は、今回の記事には記載しません。公式サイトの docs タブにまとめられています。マイグレーションを行う際には、docs 内の記事は一通り読むことをおすすめします。

Introduction · Get Started with Nuxt

移行(マイグレーション)の進め方

既存の Nuxt2プロジェクトを Nuxt3 にマイグレーションする場合、リポジトリをそのまま使うか新しく作るかの選択がありますが、新しく作ることを推奨します。

変更点は膨大になるため、既存のリポジトリをそのまま使うのは現実的ではありませんし、既存リポジトリを流用していく方法では、最初の動作確認をするまでにしなければいけないコード修正の量が膨大です。最小のコード修正で最初の動作確認ができるようにしたほうが、間違った時のコストを少なくできます。

npx nuxi init <project-name>

で新しいプロジェクトを開始し、リポジトリも新しく作ってください。

新しいプロジェクトの作成後は、まずは利用規約ページ、FAQページ、問い合わせページ等、依存リソースの少ないページを1つづつ移行していくと良いと思います。

移行にかかった時間

今回のプロジェクトは、pages が 20, components が 100 ほどの規模でしたが、空き時間にちまちまやって3週間かかりました。集中して時間がとれれば1週間ぐらいでできると思います。

  • ユニットテストはありません。
  • この時間には、スタッフによる品質検証の時間は含まれていません。

移行時の目立った問題

Vue2 で使用していたプラグインが Vue3 に対応していない場合がある

Nuxt ではなく Vue の話になるのですが、いくつかの Vue2 用のライブラリが Vue3 に対応していなため、代替を探したり自作する必要があります。

Nuxt2 から Nuxt3 のマイグレーションで、一番時間がかかったのはこの部分でした。

今回は、以下の変更がありました。

  • hooper → swiper (トップページのヒーローカルーセルで使用)
  • vue-markdown → vue3-markdown-it (MarkDown のレンダリング)
  • vue-multiselect → @vueform/multiselect (Selectウィジェットの代替)

動作に互換性は無いため、使用箇所は新しいライブラリの API に適合できるよう、大きく書き直しています。

以下のライブラリは、バージョンアップで Vue3 にも対応していたため、そのまま使用できました。(プラグインファイルだけ書き直しました)

  • v-calendar

以下のライブラリは、Vue3 に対応しておらず、代替のライブラリも無かったため、一旦機能を無効化しています。
再現するには自作する等の対応が必要になります。

  • vue-highlight-words (検索語句のハイライト)

コード修正箇所

Nuxt2 プロジェクトから Nuxt3 プロジェクトにマイグレーションする際の目立った変更箇所です。

APIプロキシ

当社のプロダクトは、 /api/ 等のリクエストをバックエンドサーバにプロキシを行うようにしています。

(Nuxt3 にビルトインされている、 /server/ ディレクトリを用いるサーバサイド API は使っていません。)

プロダクトによっては、Nuxt に入ってくる前に AWS の アプリケーションロードバランサー や Kubernetes Ingress でルーティングする場合と、一度 Nuxt で受けてから Nuxt のサーバサイドプロセスでプロキシする場合と、両方のパターンがあります。

Mac での開発環境では、Kubernetes Ingress や Nginx は使わないため、必ず Nuxtでのプロキシが必要になります。

Nuxt2 では、nuxt.config.ts の proxy 設定で書いていましたが、Nuxt 3 では本番環境で使うか (つまりビルド成果物に含めるか) どうかで2通りのプロキシ方法があります。

本番環境ではプロキシは必要なく、開発環境でだけ実現だければ良い場合

本番環境では、ALB や Kubernetes Ingress でルーティングが実現できるため必要なく、開発環境でのみプロキシを行いたい場合は、Nitro の devProxy の機能で実現できます。

主に、SSR を行わず、成果物を SSG ( generate ) して動作させる場合はこの方式になると思います。

nitro の標準機能で実現できるため、追加のライブラリは必要がなく、設定ファイルを1つ追加させるだけで可能です。

nitro.config.ts の例
import {defineNitroConfig} from 'nitropack'

function createNitroConfig() {
// 開発環境用のプロキシを設定する
const configFile = process.env.CONFIG_FILE || 'local'

const config = require(`./config/${configFile}.ts`)

if (!config.makeProxyValue) {
console.error(`./config/${configFile}.ts に makeProxyValue がありません`)
}

const proxyPaths = [
'/api/',
'/login/',
'/media/',
...
]

for (const proxyPath of proxyPaths) {
proxySettings[proxyPath] = config.makeProxyValue(proxyPath)
}
return {
devProxy: proxySettings
}
}

export default defineNitroConfig(createNitroConfig())
config/development.ts
// nitro プロキシの設定
export function makeProxyValue(path: string) {
return {
target: `https://api.example.com${path}`,
changeOrigin: true,
hostRewrite: true,
cookieDomainRewrite: true,
headers: {
'X-Forwarded-Host': 'localhost:3006',
'X-Forwarded-Proto': 'http',
'Referer': 'https://api.example.com'
}
}
}

詳しくは、 Configuration | ⚗️ Nitro の devProxy の項目をご覧ください。

本番環境でも開発環境でも同様にプロキシを行う場合

本番環境でも Nuxt のプロセス(コンテナ) でプロキシを行う場合、標準機能では実現できないため nuxt-proxy のライブラリを使います。

SSR を行う場合はこの形になると思います。

nuxt-proxy - npm

npm でインストール後、 nuxt.config.tsdefineNuxtConfigproxy 設定を追加します。

nuxt.config.ts
export default defineNuxtConfig({
  ...
  modules: ['nuxt-proxy'],
  proxy: {
    options: {
    target: ...,
changeOrigin: true,
headers: ...,
pathRewrite: {
'^/some/url/path/': '/api/path/'
...
},
pathFilter: [
'/more/url/path/',
...
]
}
}

環境設定変数の変更

Nuxt3 とは直接的な関係が薄い内容ですが、
当社では、今までのプロジェクトでは環境変数 NODE_ENV に、development, production 以外の設定名も指定していました。
例えば、ステージングサーバでは NODE_ENV=staging といった形での指定がありました。

ただし、ライブラリによっては NODE_ENVdevelopmentproduction のどちらかのみ想定しているもが多く、ビルドする上でも不都合がありましたので、 NODE_ENVdevelopmentproduction 以外の値を入れるのはやめました。

サーバ環境で設定を分岐する場合は、 CONFIG_FILE という新たな環境変数を使用するようにしています。

CONFIG_FILE で設定ファイルを指定し、記載されている設定を Nuxt に伝えるために、環境別の設定ファイルと nuxt.config.ts はこのような指定となっています。

config/devserver.ts
export const runtimeConfig = {
  // public 内で定義したものはクライアントでも使える
public: {
baseUrl: 'https://example.com',
}
}

export const proxyConfig = {
target: 'http://host.docker.internal:8000',
headers: {
'Host': 'example.com',
'X-Forwarded-Host': 'example.com',
'X-Forwarded-Proto': 'https',
'Referer': 'https://example.com'
}
}
nuxt.config.ts
const configBaseName = process ? (process.env.CONFIG_FILE || 'development') : 'development'
const configContent = require(`./config/${configBaseName}.ts`)

export default defineNuxtConfig({
// runtimeConfig は useRuntimeConfig() で参照できる
runtimeConfig: configContent.runtimeConfig,
...
modules: ['nuxt-proxy'],
proxy: {
options: {
target: configContent.proxyConfig.target,
changeOrigin: true,
headers: configContent.proxyConfig.headers,
...
}
}

※ 定義した設定をクライアント側で使うには、nuxt.config.ts の中で runtimeConfig.public に設定を入れ、クライアント側で useRuntimeConfig を実行します。

useRuntimeConfig · Nuxt Composables

vueコンポーネントの変更

script セクションは、すべて script setup に書き換えました。

setup 構文は、Vue3 の一番目立つ変更点だと思います。

Nuxt3の自動インポートの機能もあいまって、今までの Vue コンポーネントの script 部分を 1/2 程度の分量で記述でき、
とても良い開発体験があります。

多くの記事で説明されているため、概要の紹介はここでは書きませんが、ざっくり書いたカウンターのコンポーネントは以下のようになります。

<script lang="ts" setup>
const count = ref<number>(0)

function increment() {
count.value++
}
</script>

<template>
<button @click.prevent="increment">
{{ count }}
</button>
</template>

本当に必要な内容だけをコードで書けばよくなっています。コンポーネント内で、import を書くケースはほとんどありません。

以下の記事が参考になります。

【Vue.js 3.2】`<script setup>` 構文がすごくすごい

page コンポーネントの変数プレースホルダの変更

今まで、 _id.vue と命名していたファイルは、 [id].vue とつける必要があります。

components ディレクトリの自動インポート

components ディレクトリ内に書いた vue コンポーネントは、 import 文無しで使うことができます。

例えば、components/header/HeaderSearchButton.vue という名前のコンポーネントは、 インポート無し<HeaderSearchButton> として使えます。

また、 components/header/SearchButton.vue という名前のコンポーネントも、同じく、 <HeaderSearchButton> として使えます。

ディレクトリ名 + ファイル名 でコンポーネント名になりますが、ファイル名の先頭とディレクトリ名が重複する場合、重複する部分は打ち消されます。

components/global/ ディレクトリは特別で、この中に入れたものは Global を省略して、ファイル名そのままでコンポーネントとして使えます。

今までの当社のプロダクトは、区分が必要無いコンポーネントについては components/common/ ディレクトリに配置することが多かったのですが、components/common/ ディレクトリは components/global/ ディレクトリに変えるようにしています。

Vuex ストア → composables ディレクトリ内の composable 関数

Nuxt2 では、グローバルストアは Vuex + vuex-module-decorators (もしくは nuxt-typed-vuex) を使って書いていました。

Nuxt3 では、Vuex は使わなくなり、かわりに composable を使ってグローバル状態管理を構築します。

composables/ · Nuxt Directory Structure

composables/ 以下のディレクトリにある useXxxxx 関数は、自動インポートの対象になります。

例えば、vuex-module-decorators では、カウンターの Vuex ストアは以下のように書いていました。

Nuxt2: store/counter.ts ( vuex-module-decorators の場合)
import { Module, VuexModule, Mutation, Action } from 'vuex-module-decorators'

@Module({
name: 'counter',
stateFactory: true,
namespaced: true
})
export default class extends VuexModule {
count: number = 0

get doubleCount (): number {
return this.count * 2
}

@Mutation
setCount (value: number) {
this.count = value
}

@Action({ rawError: true })
async increment () {
this.setCount(this.count + 1)
}
}

nuxt-typed-vuex で書いた場合は以下のようになります。

Nuxt2: store/counter.ts ( nuxt-typed-vuex の場合)
import { getterTree, mutationTree, actionTree } from 'typed-vuex'

export const state = () => ({
count: 0 as number
})

export type RootState = ReturnType<typeof state>

export const getters = getterTree(state, {
doubleCount(state): number {
return state.count * 2
}
})

export const mutations = mutationTree(state, {
setCount(state, count: number) {
state.count = count
}
})

export const actions = actionTree(
{ state, mutations },
{
increment({ commit }) {
commit('setCount', state.count + 1)
}
}
)

Nuxt3 composable の場合、composable を使って以下のように書きます。

composables/counter.ts
export const useCounterComposable = () => {
const count = useState<number>('count', () => 0)

const doubleCount = computed(() => count.value * 2)
const increment = () => {
count.value++
}

return {
count,
doubleCount,
increment,
}
}

Vueコンポーネント内で使う際は、このようになります。

composables/counter.vue
<template>
<button @click.prevent="counterComposable.increment" >
{{ counterComposable.count}} * 2
= {{ counterComposable.doubleCount }}
</button>
</template>
<script lang="ts" setup>
const counterComposable = useCounterComposable()
</script>

Vuex Store から composable 関数へのマイグレーションは、完全に 1:1 で行えます。
(ミューテーションは不要になります。)

ファイル名はそのままに、手動で機械的に composable 関数に変換していくと良いでしょう。

注意点

composables/counter.ts の

const count = useState<number>('count', () => 0)

は、

const count = ref<number>(0)

と、ref を使って書いても良さそうに見えます。実際それでも動くのですが、refsetup セクション以外で使うとサーバで状態が共有されメモリリークが発生するため、 setup セクション以外では使えません。

State Management · Get Started with Nuxt

useState の第一引数のキー名は、利用者のアプリ内で一意のものであり、キー名が一致したらどこでコールしても共通のカウント数が取得できます。

const count = useState<number>('count', () => 0)

ただし、使用箇所が分散するとメンテナンスが難しくなるため、composables/ の中だけで扱うと決めるのが良いと思います。

サイトすべてで共通の HTML の head セクション

title タグ、viewport や文字コード等の meta タグ、共通スタイルシートの link タグなどの、サイト内で共通の HTML の head セクションの定義は2通りの方法があります。

nuxt.config.ts の app.head に書く

Nuxt2では、nuxt.config.tshead というセクションに書いていましたが、Nuxt3 以降は app.head に書きます。

Nuxt Configuration Reference · Nuxt #head

基本的な書き方は変わっていません。

app.vue で useHead を使う

一番大枠のVueコンポーネントである、app.vue に、script setup を作り、useHead 関数を使って Head 項目の定義をすることもできます。

nuxt.config.ts で定義すれば良いものなので基本的には使うことは無いと思いますが、昔にこの形式でやってたこともあるので、これでも設定できることを書き残しておきます。

テンプレートフィルタ構文の廃止

テンプレートでの、下記のようなフィルタ構文廃止になり、Vue3 からは使えません。

{{ taxIncluedTotalPrice | addComma }}

そのため、普通の関数に変更する必要があります。

{{ $addComma(taxIncluedTotalPrice) }}

プラグインの書き方の変更

上記、addComma 関数は、プラグイン関数として定義すると、どこからでもインポート無しで使えて便利です。プラグイン関数はこのように書きます。

plugins/filter.ts
export default defineNuxtPlugin((nuxtApp) => {

/**
* 金額をカンマ区切りに表示します。
* $addComma(1000) => 1,000
*/
nuxtApp.provide('addComma', function (val: number) {
if (val === 0) {
return '0'
}

if (!val) {
return ''
}

if (typeof val === 'string') {
val = Number(val)
}

return val.toLocaleString()
})
})

nuxtApp.provide を実行することでで、システムグローバルに $xxxxx という名前で使える関数を定義できます。
テンプレート内でも、script setup 内でも使えます。

app.use する場合

v-calendar のように、Vue3 で app.use でプラグインを登録するライブラリを Nuxt3 で使う場合はこのように書きます。

Vue 3 | V-Calendar

plugins/v-calendar.ts
import {defineNuxtPlugin} from 'nuxt/app'
import VCalendar from 'v-calendar'

// https://vcalendar.io/vue-3.html
export default defineNuxtPlugin((nuxtApp) => {
if(process.client) {
nuxtApp.vueApp.use(VCalendar, {})
}
})

ページを遷移した時に自動的にページの先頭にスクロールアップするプラグイン

ページを移動した時にページの先頭にスクロールアップし、さらにブラウザを戻った場合に前回見ていたスクロール位置をキープする必要がある時、下記ディスカッションで書かれているコードを適用すると良いです。

scrollToTop in v3 ? · Discussion #1661 · nuxt/framework

このディスカッションの、この発言が要件を満たす完璧なコードです。

https://github.com/nuxt/framework/discussions/1661#discussioncomment-3967225

長くて仰々しいですが、使用感は一番良いです。

とはいえ…正直な所、JS のフレームワークを使っている以上、ブラウザの「戻る」の体験は、ページごとに HTML を返すクラシックなスタイルに並ぶまでは至りません。

検索結果のリストを表示して、クリックして詳細表示に遷移し、ブラウザの戻る機能で戻り、その下のものをクリックして…といった当たり前に行う操作において、クラシックなHTMLアプリに近い操作感に達するまでに、書かなければいけないコードや気にしなければいけないことが多すぎます。今後も研究していく課題だと思っています。

データフェッチ周りの改修

当社では、Nuxt2 では axios を使ってデータフェッチを行うこと多かったですが、Nuxt3 からは ohmyfetch 改め ofetch を使います。

リアクティブな状態変化に対応できるのは良いのですが、サーバでフェッチした内容がクライアントにハイドレーションされる時の挙動など慣れが必要となると思います。

また内容をキャッシュする機能があり、場合によっては意図しない所で内容がキャッシュされていまい、利用者が操作しても内容が切り替わらないこともよくあります。

データフェッチ用の関数も、 useAsyncData, useLazyAsyncData, useFetch, useLazyFetch, $fetch と、いくつもあります。

Data Fetching · Get Started with Nuxt

await useFetch('/api/count') と書いた場合、クライアント側とサーバ側で処理が変わります。

これは、私のプロダクトが /server/api/ を作っておらず、外部サーバへプロキシしているためかもしれません。

サーバ側で、 useFetch('/api/count') が発生した場合、リクエストするホスト名が不明なため、リクエストが失敗します。

そのため、サーバ側では、useFetch のオプションの baseUrl でスキーマとホストhttps://example.com を指定するか、リクエスト先のURLの先頭にスキーマとホスト等をつけて、 'https://example.com/api/count' といった完全な形のURL に変換する必要があります。

リクエストヘッダについても、HostAccept 等のヘッダを必要に応じて付与します。サーバサイドプロセスから外部のサーバにリクエストする場合、プロキシではないため nuxt.config.ts の proxy の設定は使われません。少し混乱しやすい箇所だと思いますのでご注意ください。

また、useFetch のキャッシュのキーの生成についても、私の使い方の問題だとは思うのですが、期待通りに一意のキーができてないように思うので、 useFetch のラッパーを作って明示的にキーを作っています。

export async function useFetchAPI<T>(url: string, options: any = {}) {

if (!options.key) {
// キャッシュキーを明示的に作る
options.key = url + JSON.stringify(options)
}
let requestUrl: string = url
if (process.server) {
// サーバリクエストの場合は完全な URL を作ってリクエストする
const runtimeConfig = useRuntimeConfig()
options.baseURL = runtimeConfig.proxy.options.target

// Docker 内から host.docker.internal にアクセスする際に Host ヘッダを付与する
if (runtimeConfig.proxy.options.headers.Host) {
if (!options.headers) {
options.headers = {}
}
options.headers.Host = runtimeConfig.proxy.options.headers.Host
}
}

return await useFetch<T>(
requestUrl, options)
}

$fetch は、 axios の .$get のように、レスポンスの中で必要なコンテンツのみを返してくれる関数ですが、axios の .get や、python の requests, また生の fetch のように、リクエストの結果をレスポンスオブジェクトとして取得し、レスポンスオブジェクトの HTTP ステータスや Content-Type を見て処理を分岐するといったコードは書けません。

ただ、データの Put や Post 等の更新系のリクエストは、$fetch を使わずにもっとプリミティブなレスポンスを扱ってエラーハンドリングをしたいのと、CSRF を防ぐためのトークン送信なども必要になると思いますので、$fetchuseFetch を使わず、 fetch のラッパーを作って使っています。

package.json

Nuxt3 の場合、 package.jsondependencies空のオブジェクトにして、必要な依存関係はすべて devDependencies に書きます
Svelte でもそうで、Vite を使う場合は基本的にこの形になるのだと思います。

package.json
{
"private": true,
"scripts": {
"build": "nuxt build",
"build:devserver": "CONFIG_FILE=devserver nuxt build",
"build:production": "CONFIG_FILE=production nuxt build",
"dev": "PORT=3006 nuxt dev",
"dev:local": "CONFIG_FILE=local PORT=3006 nuxt dev",
"generate": "nuxt generate",
"preview": "PORT=3006 nuxt preview",
"postinstall": "nuxt prepare"
},
"devDependencies": {
"nuxt": "3.0.0",
"sass": "^1.56.1",
"@vueform/multiselect": "^2.5.6",
"nuxt-proxy": "^0.3.4",
"swiper": "^8.4.4",
"v-calendar": "^3.0.0-alpha.8",
"vue3-markdown-it": "^1.0.10"
},
"dependencies": {
}
}

ビルドを行うと、nitro/h3 の Webサーバエンジンも含めたすべての依存ライブラリを output ディレクトリにまとめて書き出します。
output ディレクトリさえあれば他に依存せずアプリを動作させることができるようになっています。

Dockerfile

動作時に外部の依存ライブラリが必要無いということは、 Dockerfile をかなりシンプルに書けます。

Dockerfile
FROM node:16-slim

WORKDIR /app

COPY .output /app/.output

USER nobody
CMD [ "node", ".output/server/index.mjs"]

当社の環境では、ビルドごとに Docker イメージを作っています。
.output ディレクトリを実行環境にコピーできれば、node の docker コンテナにマウントさせて実行させるのも簡単なため、独自の Dockerイメージすら必要無いでしょう。

本番の実行環境の構築が非常に楽になったのは Vite を使うようになってからの大きな利点だと感じます。

Raspberry Pi Pico W で Httpサーバ(microdot)とセンサーによるHTTPリクエスト機能を同時に稼働させる

Raspberry Pi Pico W が発表されました。日本ではまだ未発売ですが、技適は取得されたようですので近いうちに国内販売がされそうです。

試しに、Webサーバ ( Microdot )とWebクライアント(urequest) を uasyncio で並列実行するコードを書きましたので、紹介します。

今回作成したコードや動作している動画は、Github で公開しています。

ytyng/rpi-pico-w-webserver-and-client: Raspberry Pi Pico W webserver and client sample code

Raspberry Pi Pico W とは

コストパフォーマンスが高いマイクロコントローラです。カテゴリとしては Arduino 等に近く、今までの Raspberry Pi のように、Linux OS を動作させるようなマシンではありません。

RP2040 というラズベリーパイ財団が開発したチップのデモボードという位置づけとなります。

実際の商品開発では、Raspberry Pi Pico で製品のR&Dを行い、実際は RP2040 を搭載した製品として生産するという流れとなると思いますが、ホビーや SOHOでは Raspberry Pi Pico をそのまま使うことも多いと思います。

実際、当社でも Raspberry Pi Pico を用いてイベント用の機材を作る場合がありますが、
RP2040 を使ったの製品を作るわけではなく、Raspberry Pi Pico をそのままケースに入れて使います。

MicroPython が動作するため、Python に慣れていれば開発は容易にできます。

商品名に W がつかない今までの機種は、ネットワーク機能はありませんでしたが、今回 Raspberry Pi Pico W となって無線チップが搭載され、コストパフォーマンスと使い勝手が最高の IoT デモボードとなりました。

↑ 左が Raspberry PI Pico, 右 が無線LAN チップが搭載された Raspberry Pi Pico W

考えられる用途

Raspberry Pi Pico W の用途で多く使われると考えられる用途は、

  • 接続させているデバイスのセンシング情報を元に、HTTP リクエストを発生させる
  • HTTP サーバを起動し、外部から HTTP リクエストを受け取って、接続されているデバイスを動作させる

この2つが主なものとなると考えられます。

今回は、この2つを Raspberry Pi Pico W の中で同時に実行する方法を書きます。

一通りのチュートリアル

Raspberry PI の公式ページが提供している PDF が充実います。

https://datasheets.raspberrypi.com/picow/connecting-to-the-internet-with-pico-w.pdf

ただ、PDF なので少し読みにくいのと、Thonny に関しては言及されていないため、Mac や Windows を普段使われている方は、この PDF だけでなく、他のサイトで紹介されているような Thonny を使ったセットアップを行うと良いでしょう。

ファームウェアの準備

https://micropython.org/download/rp2-pico-w/

上記 URL で、Raspberry Pi Pico 用の MicroPython ファームウェアの uf2 ファイルが入手できます。

最新版への直リンクはこちらです。 https://micropython.org/download/rp2-pico-w/rp2-pico-w-latest.uf2

ファームウェアのファイルをダウンロードし、 Pico へコピーしてください。

W 対応でない uf2 ファームウェアは別に存在します。そちらを使った場合、Wi-fi の機能が使えませんのでご注意ください。

コピー方法

Pico の BOOTSEL ボタンを押したまま USB で PC に接続すると、PCが Pico をストレージとして認識します。

ダウンロードした uf2 ファイルを Pico にドラッグアンドドロップでコピーすると、自動的にファームウェアがロードされ、 Pico が再起動します。

Wifi に接続する

一番最初に、Wifi に接続する必要があります。
SSID と パスワードが変数化されていれば、後は簡単なコードで接続が行えます。

接続用の関数を作っておくと便利で、他の方を見ても関数化しているようです。

StackOverflow の話題を見ると、Wifi との接続は main.py の中でやらずに boot.py の中でやったほうがいい、というコメントをいくつか見かけましたが、私は 開発のしやすさから main.py の中で行うようにしています。

Wi-fi に接続するコード

https://github.com/ytyng/rpi-pico-w-webserver-and-client/blob/main/network_utils.py

import rp2
import network
import uasyncio
import secrets


async def prepare_wifi():
"""
Prepare Wi-Fi connection.
https://datasheets.raspberrypi.com/picow/connecting-to-the-internet-with-pico-w.pdf # noqa
"""
# Set country code
rp2.country(secrets.COUNTRY)

wlan = network.WLAN(network.STA_IF)
wlan.active(True)

wlan.connect(secrets.WIFI_SSID, secrets.WIFI_PASSWORD)

for i in range(10):
status = wlan.status()
if wlan.status() < 0 or wlan.status() >= network.STAT_GOT_IP:
break
print(f'Waiting for connection... status={status}')
uasyncio.sleep(1)
else:
raise RuntimeError('Wifi connection timed out.')

# CYW43_LINK_DOWN (0)
# CYW43_LINK_JOIN (1)
# CYW43_LINK_NOIP (2)
# CYW43_LINK_UP (3)
# CYW43_LINK_FAIL (-1)
# CYW43_LINK_NONET (-2)
# CYW43_LINK_BADAUTH (-3)

wlan_status = wlan.status()

if wlan_status != network.STAT_GOT_IP:
raise RuntimeError(
'Wi-Fi connection failed. status={}'.format(wlan_status))

print('Wi-fi ready. ifconfig:', wlan.ifconfig())
return wlan

接続させているデバイスのスイッチ(センサー)情報を元に、HTTP リクエストを発生させる

Raspberry Pi Pico W Wi-Fi Doorbell tutorial (HTTP requests & IFTTT) — PiCockpit | Monitor and Control your Raspberry Pi: free for up to 5 Pis!

こちらの方が開発されているドアベルのコードが参考になります。
Youtube 動画もあってわかりやすいです。

urequests

Python でよく使う、requests ライブラリに変わり、MicroPython では似たような使い勝手の urequests ライブラリを使うことができます。

ネットワーク接続が確立されていれば、あとは urequests.get(...) 等で簡単にリクエストが発行できます。

Thonny の tools -> Manage packages からインストールできます。

HTTP サーバとして稼働させる

ソケットをそのまま使って簡易的な HTTP サーバにする

こちらの記事が参考になりました。大変わかりやすく日本語で説明されているので、Pico の初学者にもおすすめします。

Raspberry Pi Pico W で無線Lチカ

リンクされている、mimoroni 社のコードは、 Pico 用の拡張されたファームウェア

https://github.com/pimoroni/pimoroni-pico/releases

や、 Pico W 用の各種ユーティリティコードがあり、開発の参考になります。

このコードの HTTP サーバの部分は、TCP ソケットをそのまま使い、リクエスト本文の中のパス名と文字列一致して判定してい分岐を行っています。

Raspberry Pi 公式のチュートリアルPDFでもその方式で行っていました。

規模が小さいようであれば十分だと思いますが、HTTP ヘッダーを扱いたい場合や、少し規模を拡張したい場合はこの形では難しいでしょう。

Microdot を起動する

Flask や Bottle、fastApi が動けば良いのですが、現状は動作しません。
代わりに、Microdot という ウェブフレームワークがあり、使い勝手としては Flask や Bottle によく似ていて大変勝手が良いです。

こちらを使って ウェブサーバを起動してみます。

Microdot

Thonny で Tools -> Manage packages からインストールすることができます。

ネットワーク接続が確立したら、

app = Microdot()

@app.get('/')
async def _index(request):
return 'Microdot on Raspberry Pi Pico W'

app.run(port=80)

このような親しみやすいコードで HTTP サーバが起動します。

ウェブサーバとセンサーリクエストを同時に使う

Raspberry Pi Pico は、通常シングルスレッド動作です。(ちなみにCPUはデュアルコアです)

一応、 _threading という疑似スレッドができるライブラリはありますが、処理によっては本体が暴走したり固まることが多く、かなりおすすめしません。
暴走すると、最悪、何度もファームウェアのリセットをするこになり、開発体験は良くありません。

代わりに、 asyncio を使ったコルーチン処理を標準で行うことができ、こちらは安定して動作しますので、 Pico で開発する際は、基本的にメソッドはコルーチンで書くのをおすすめします。

Pico は、待機ループで sleep を使うことも多いですし、コルーチンと相性が良いと感じます。

Microdot も非同期対応の起動ができるものが既に開発されています。

Pico 上の MicroPython でのコルーチンは、通常の Python にビルトインされている asyncio を使うのではなく、
uasyncio というパッケージを使います。

Pico 用の uf2 ファームウェアに含まれていますので、別途新たなインストールは必要ありません。

例えば下記のようなコードで、asyncio が有効な処理を開始することができます。

import uasyncio

async def main():
uasyncio.create_task(any_async_method())
await other_async_method()


if __name__ == '__main__':
    uasyncio.run(main())

Pico の起動後、無線 LAN に接続した後は、スイッチ押下待機のループと、Micorodot の起動を
両方ともコルーチンで書くことで、無理なく並列動作をさせることができます。

実際に動作するコードは Github で公開しています。

rpi-pico-w-webserver-and-client/main.py at main · ytyng/rpi-pico-w-webserver-and-client

メインのコードとしてはこのようになります。

"""
Raspberry Pi Pico Web Server with Microdot and Switch Sample Code.
Pin 14 is used for switch input.
"""
import machine
import urequests
import network_utils
from microdot_asyncio import Microdot
import uasyncio


async def switch_loop():
"""
Switch listener loop
Pin 14 is used for switch input.
When press switch, send request to http web server.
"""
print('start switch_loop')
switch_pin = machine.Pin(14, machine.Pin.IN, machine.Pin.PULL_DOWN)

while True:
current_state = switch_pin.value()
if current_state:
# Change the URL to your own server, IFTTT, Slack, etc.
response = urequests.get('https://example.com/')
print(response.content)
response.close()
await uasyncio.sleep(2)
else:
await uasyncio.sleep(0.1)

async def run_web_server():
"""
Start microdot web server
https://microdot.readthedocs.io/en/latest/index.html
"""
app = Microdot()
led_pin = machine.Pin('LED', machine.Pin.OUT)

@app.get('/')
async def _index(request):
return 'Microdot on Raspberry Pi Pico W'

@app.get('/led/<status>')
async def _led(request, status):
"""
/led/on : LED ON
/led/off : LED OFF
"""
if status == 'on':
led_pin.on()
return 'LED turned on'
elif status == 'off':
led_pin.off()
return 'LED turned off'
return 'Invalid status.'

print('microdot run')
app.run(port=80)


async def main():
wlan = await network_utils.prepare_wifi()
print('LED ON: http://{}/led/on'.format(wlan.ifconfig()[0]))

uasyncio.create_task(switch_loop())
await run_web_server()


if __name__ == '__main__':
uasyncio.run(main())

Svelte で作ったWebコンポーネントを接続国によって出し分ける

概要

11月28日、当社 TORICO の初の海外店舗、マンガ展 台湾 がオープンしました。

漫畫展 台灣

オープンする直前で、「漫画全巻ドットコム、スキマ、マンガ展、ホーリンラブブックスのサイトに、台湾からアクセスされた方に告知を出したい。告知を1回クリックしたらもう出さないようにしたい。」という開発要件が出たので、作ってみました。

接続元の判定と出し分け

今回は、 AWS の CloudFront で、接続元の国名のヘッダを付与する機能を使うことにしました。

CloudFront の入口でリクエストヘッダが付与されますので、CloudFront Functions でそのヘッダを見て動的な処理が行えます。
ヘッダに応じて、対象国であれば、バックエンドのパスを変化させることで、接続国に応じた処理を行えるように設計しました。

サーバの管理はなるべく減らしたいため、今回は完全にサーバレスでサービスを作っています。動的な処理は、CloudFront Function を使いました。

コンポーネントの開発

全サイトに共通のモーダルポップアップ表示を行う必要があります。当社エンジニアのまるさんから、Svelteを進められたので、Svelte で Web コンポーネントを書きました。

完成物

これらのサイトに、台湾からアクセスすると、モーダルポップアップが表示されます。

仕組みとしては、リクエストするスクリプトの内容が、接続国に応じて変化するようになっています。

Svelte で Web コンポーネントを作る

Svelte の概要

Svelte は、Vue のシングルファイルコンポーネントによく似た形で、1ファイルで1コンポーネントをちょうどよく書けます。

CSS はスコープドなものになり、変数は特に意識せずともリアクティブに扱うことができます。

Web コンポーネントとは、JS によって作られた独自の HTML タグをどんなサイトでも使えるようにする技術です。
コンポーネントを定義した JS ファイルをロードすることで、そのサイトで <my-component></my-component> のような独自のタグを使えるようになります。
そのサイトが 素の HTML + jQuery で作られているサービスでも、React や Vue で作られているサイトでも、Google Tag Manager からでも同じようにコンポーネントが使えます。

複数サービスで共通のチャットウィジェットや、広告ウィジェットの開発に適しています。

プロジェクトの開始

Svelte のプロジェクトの開始方法は、チュートリアルがあるのでこの手順で作成できます。

https://svelte.jp/docs#getting-started

npm create vite@latest myapp

対話的に質問されますので、適切に答えます。

Select a framework: Svelte
Select a variant: TypeScript

※ SvelteKit は今回使いませんでした。
単純な Web コンポーネントであれば、特に使わなくても良いと思います。

起動

npm run dev

カウンターが起動します。

Webコンポーネント化する

このカウンターを、Webコンポーネントとしてビルドをできるようにします。

実際の商用コードはカウンターとは違うものですが、今回は例としてカウンターのコンポーネントを使います。

Svelte コンポーネントを Web コンポーネントとして書き出すには、既に良い記事がいくつかあります。

SvelteではじめるWeb Components開発 - Qiita

src/main.ts の内容を下記の1行に修正

export * from './lib/Counter.svelte'

src/lib/Counter.svelte の最上部に1行追加

<svelte:options tag="my-counter" />

ルートディレクトリの index.html の内容を書きに修正

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<link rel="icon" type="image/svg+xml" href="/vite.svg" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Vite + Svelte + TS</title>
</head>
<body>
<my-counter></my-counter>
<script type="module" src= "/src/main.ts"></script>
</body>
</html>

vite.config.ts を以下のように修正します。

import {defineConfig} from 'vite'
import {svelte} from '@sveltejs/vite-plugin-svelte'

// https://vitejs.dev/config/
export default defineConfig({
build: {
lib: {
entry: './src/main.ts',
name: 'my-counter',
fileName: (format) => `my-counter.${format}.js`,
formats: ['es'],
},
},
plugins: [svelte({
compilerOptions: {
customElement: true,
},
}),]
})

formats については、 ブラウザ用の JS を作るか、サーバ用の JS を作るかでいくつかの形式を指定できます。
デフォルトでは esumd で、umd はサーバサイドでの実行に使うものです。今回は、ブラウザ JS だけあれば良いので、es のみにしています。

独自のコンポーネントを開発する

今回は、開発したプロダクションコードの具体的な内容は割愛します。

開発サーバを実行

npm run dev

ビルド

動作が確認できたら、JS ファイルをビルドします。

npm run build

dist/my-counter.es.js が作成されます。

成果物のテスト

ビルド成果物を確認するには、プロジェクトのルートディレクトリに

<my-counter></my-counter>
<script type="module" src= "dist/my-counter.es.js"></script>

の内容を含む HTML を作り、ダブルクリックで起動すると良いと思います。

npm run preview というコマンドもありますが、dist ディレクトリ以下に index.html が必要で、
dist ディレクトリはビルドするたびに消えてしまうのでコンポーネント開発では使いづらそうです。

実際に他のサービスからコンポーネントを使う際も、上記のようなスクリプトタグで使うことができます。その際、 script タグに type="module" を忘れずに指定します。ビルドしたコードには、ファイル直下に $ といった短い名前の関数が作られます。そのため、type="module" なしでグローバル領域に読み込んだ場合、既存のスクリプトで jQuery 等を使っている場合に誤動作につながります。

なお、type="module" をつけた場合、そのスクリプトは CORS 判定の対象となりますので、サーバ側は access-control-allow-origin の HTTP ヘッダを必ず返す必要があります。

S3の設定

本番環境で使えるようにするにするため、ビルド成果物の JS を、S3 にデプロイして静的サイトホスティングの機能でホスティングします。

バケットの命名の注意

S3 のバケットを作る際は、バケット名をサービスを提供する URL のホスト名と完全に同じにする必要があります

CloudFront で、CloudFront Functions を使ってリクエストヘッダーを操作する場合、S3に伝わる Host ヘッダーは必ずリクエストしている Host ヘッダーとなり、 Functions 内で変更することは制限されておりできないためです。

静的ウェブサイトホスティングの設定

Hosting a static website using Amazon S3 - Amazon Simple Storage Service

S3 の「プロパティ」タブの一番下から設定します。

バケットポリシーの設定

「アクセス許可」タブ内にバケットポリシーの設定欄があります。

パブリックでの読み取りを許可するポリシーにします。

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicRead",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::world-visitor.torico-corp.com/*"
}
]
}

CORSヘッダーの設定

「アクセス許可」タブ内の一番下に Cross-Origin Resource Sharing (CORS) の設定欄があります。

[
{
"AllowedHeaders": [
"Authorization"
],
"AllowedMethods": [
"GET",
"HEAD"
],
"AllowedOrigins": [
"*"
],
"ExposeHeaders": []
}
]

ファイルのデプロイ

ビルド成果物を S3 にアップロードします。

接続国により2つのファイルを出し分ける設計とするため、今回のビルド成果物の他に、空の JS も別のファイル名でデプロイしておきます。

CloudFront の設定

オリジン

先程作成した、S3 の WebホスティングのURLをオリジンとします。

接続国に応じてリクエストヘッダーを付与する設定

CloudFront の「オリジンリクエストポリシー」という機能で、リクエスト国別のヘッダを付与することができます。

CloudFront の ポリシーページの、オリジンリクエストのカスタムポリシーで、「オリジンリクエストポリシーの作成」を選択し、追加するヘッダーを選べます。

Adding the CloudFront HTTP headers - Amazon CloudFront

CloudFront-Viewer-Country を追加すると、ヘッダーの値として2文字の国名コードが追加されます。「JP」等。大文字になります。

リクエストヘッダによってオリジンに要求するファイルのパスを変えるファンクション

付与したリクエストヘッダーを CloudFront Functions で判定し、リクエストパスを変化させます。
今回はこのようなスクリプトになりました。

なお、handle の引数の event の構造はこのページで紹介されています。

CloudFront Functions event structure - Amazon CloudFront

/*
接続元の国によってリクエストパスにプレフィックスをつけるファンクション
*/

/// 国コードを取得
function getCountryCode(event) {
return event.request.headers['cloudfront-viewer-country']
? event.request.headers['cloudfront-viewer-country'].value
: ''
}

/// 国コード(大文字)から判断するディレクトリプレフィックス
/// SG は初回は必要無いが、検証のために追加
function getDirectoryPrefix(countryCode) {
if(['TW', 'SG'].includes(countryCode)) {
return '/tw';
}
return ''
}

/// uri (パス) はルーティング対象か
// 検証用の index.html はルーティングしたくない。
function uriRootingRequired(uri) {
return ['/my-component.es.js'].includes(uri);
}

function handler(event) {
var countryCode = getCountryCode(event);
var directoryPrefix = getDirectoryPrefix(countryCode);
if (directoryPrefix && uriRootingRequired(event.request.uri)) {
event.request.uri = directoryPrefix + event.request.uri;
}
return event.request;
}

Google Tag Manager でロードする

今回作った Svelte のコンポーネントは、 Google Tag Manager からでも使うことができます。

ただし、Google Tag Manager で独自の HTML タグを書くとエラーとなって公開できないため、
document.createElement でタグを作成しています。

また、script タグに type="module" 忘れずに指定します。これをつけないとグローバル変数領域にロードされてしまうため、既存のスクリプトに悪影響があります。

そして、type="module" を入れた場合、なぜか「document.writeをサポートする」にチェックが入ってないとスクリプトが動作しないため、チェックを入れます。

電子書籍の無料ページが変わりました(漫画全巻ドットコム)



こんにちは、品質管理係の渡辺です。
日々、システムのテストをしていると、新機能に出会えていち早く動かすことができて面白いです。

漫画全巻ドットコムは、徐々に「PHP」から「Nuxt.js+Django」への移行している過程で、各ページもリニューアルしています。
そのうちの一つに電子書籍無料ページにある作品の表示方法を改良しました。

以前の陳列方法は無料の巻数全てを表示
漫画全巻ドットコムには、電子書籍無料ページがあります。
以前は、同じ作品が1~3巻が無料の時は、1~3巻の3冊とも並べていました。
以前の陳列方法
そのため、「24時間100巻無料」というキャンペーンがある時は、1ページまるまる同じ作品が並ぶこともありました。
単行本(単巻)の場合はまだ巻数ごとに表紙イラストが違うので楽しめましたが、「黒崎秘書に褒められたい【マイクロ】」のような単話売り無料だった時は、ほぼ同じ表紙イラストがたくさん並ぶことになります。

単話

そうなると、同時期に無料である他の作品が目立たなくなるデメリットがありました。

商品陳列を1作品につき1冊置きにしました
そこで、ユーザーの目により多くの別作品も見つけてもらえるように、まずは同じ作品が複数巻無料であっても最初の1冊だけを並べるようにして、商品を増やすことにしたところ、ページの商品が充実されました。
1ページで見れる商品が増えて、バラエティー豊かなページになりました。
陳列方法は1冊置き

また、同時に表紙イラストの上部に【1~3巻無料】を表記されているので、いま読める無料巻が何冊あるか、すぐに分かるように工夫もしています。



なお、作品によっては単話売りと単巻売りがあります。
その場合は、単話売り、単巻売りが独立した1つずつの商品となっているので別々に表示されます。
単話・

このように、よく同時に無料になる事があるので、並んで表示されている事もしばしばあります。

無料巻から続く巻も分かりやすくなりました
表紙イラストをクリックすると、作品の販売中の巻数がすべて表示されるようになりました。
続巻

この機能が付いたことにより、どのようなキャンペーンでも同じ作品であれば、無料、割引、通常がこのページでいっぺんに表示されます。(無料が優先されます)
これで、花とゆめコミックスの最新刊記念で1巻と前巻が無料キャンペーンなどがある場合でも、すべての巻を枠内でスクロールするだけで、確認することができるようになりました。
このように、連続した巻ではなく、所々選りすぐりの巻を持ちいて、無料・割引とするキャンペーンは、意外と多いのです。
以前は、隣同士の陳列のみだったのでページを跨いでしまった時など、次にもあることを気づかず読めてかった人も、この機能で今度からは、
連続巻ではない無料巻も逃さず読めるようになったことでしょう。

ぜひこれからも、新たな作品の出会いの場として、漫画全巻ドットコムの電子書籍の無料ページをお気軽に閲覧してみてください。

漫画全巻ドットコムTOP → https://www.mangazenkan.com/

PC設定でキーボードのキー配置が換わる(Windows11の設定)

キーボード画像

こんにちは、品質管理係の渡辺です。
今回はキーボードの設定についてお話します。
以前、外部付けキーボードを試すことがありました。
特にキーボードの設定はせずに、いつものようにキーを打つと、あれっ?と違和感がありました。
違和感の正体は、キーの面に記していない文字・記号が画面に表示されることでした。
よくよくキーの配置を観察しながら、打ってみると、画面に表示されたのは、キーの隣や下にあるキーの文字・記号でした。
具体的には「@」のキーを押すと「 [ 」、「 [ 」を押すと「 ] 」、「半角/全角」を押すと「’」が表示されました。
すぐに「ひらがな入力」「半角/全角入力」「ローマ字入力」などの入力方式を切り換えを試しても解決できませんでした。

「英語キーボード」「日本語キーボード」
そこで、ネットで調べたところ、キーボードのキー配置はいろいろな形があり、国内で主流になっているのは「英語キーボード」と「日本語キーボード」の2種でした。

英語キーボード(Windows11タッチキーボード)
英語キーボード
日本語キーボード(Windows11タッチキーボード)
日本語キーボード

画像のようにキーの個数が異なるため、アルファベットは同じ位置ですが、記号の配置は違っていました。
Windowsでは、キーボード設定で、変更もできるので、どちらのキーボードも使用できます。
もし、キーに記されている@マークが表示されない時は、一度設定を見直してみてください。
次は設定の見直しと変更の仕方を述べていきます。

Windows11 のキーボード設定
ここではWindows11の設定方法です。(Windows10以前では設定場所が異なるかもしれません)

1.Windowsアイコンをクリック > 設定(アイコン)をクリック
マウスの右クリック、左クリックで表示が違いますが、どちらからでもOKです。

▽右クリックした時の画面
右クリック
▽左クリックした時の画面


2. サイドメニューの「時刻と言語」(①)を押す > 「地域と言語」(②)を押す
時間と言語

3. 「優先する言語」にある「日本語」の3点アイコンを押す
(無ければ、言語の追加で日本語を選ぶ) 
優先する言語

4. 「言語のオプション」を押す
言語のオプション

5. 「キーボード」の「レイアウトを変更する」を押す
キーボードレイアウト

6. 「ハードウェアキーボードレイアウト変更」画面で選択の中から「日本語キーボード」を選択する
キーボード選択

7. 選択後は、「今すぐ再起動する」を押す
今すぐ再起動


以上で、キーボードの切り替え設定は完了しました。
再起動後、赤枠のキーを打ってみてください。キーに記された記号が画面に表示されれば、設定完了となります。
確認のキー


実は、スクリーンキーボードでも設定を確認できました
後日、知ったのですが、いまがどっちのキーボード設定なのかを確認する方法は、もう一つありました。
それは、パソコンに搭載のスクリーンキーボード(ショートカットは【Windowsロゴ + Ctrl + O】)を表示するだけで確認することができました。

▽英語(US)キーボード設定
スクリーンキーボード(英語キーボード)

▽日本語キーボード設定
スクリーンキーボード(日本語キーボード)

今回のキーボードのお話はこちらで終わりです。






照合順序が違うカラムの外部結合

増築を繰り返しているMysqlデータベースを使用しているとたまにある問題の解決方法

作成されたタイミングの違うテーブルの照合順序があっていないことがあります。
古いテーブルのカラムの照合順序がutf8_unicode_ciで、
最近作られたテーブルのカラムの照合順序がutf8_general_ci
必要データがこのふたつのテーブルにあるため外部結合しなければならない自体になった。

普通にLEFT JOINしようとすると

SELECT t1.*
FROM t1
LEFT JOIN t2
ON t1.code = t2.code

照合順序が違うカラム同士では外部結合できないとエラーが発生します。

Illegal mix of collations (utf8_unicode_ci,IMPLICIT) and (utf8_general_ci,IMPLICIT) for operation '='

これの解決のためにカラムの設定を変えてしまうのは影響範囲が大きいのでできれば避けたい。
そんな場合にはCOLLATE句を使用することで解決できます。

SELECT t1.*
FROM t1
LEFT JOIN t2
ON t1.code COLLATE utf8_general_ci = t2.code

これで問題なく外部結合して結果を取得することができました。

mysqlのドキュメントにはWHERE句、ORDER句、GROUP句などでの使い方は書いてありましたが、外部結合での使い方は書いてなかったので備忘録として残しておきます。

MySQL 5.6 リファレンスマニュアル 10.1.7.2 SQL ステートメントでの COLLATE の使用

【合格体験記】3週間でAWS Certified Solutions Architect - Associate (SAA)を取得した話

エンジニアの高津です。

8/6にCLF、8/26にSAAに合格したのでそれについて書いていこうと思います。

なぜ受けようと思ったのか

会社からの推奨もあって4月に基本情報技術者試験を受けたのですが、

「基本情報くらいノー勉で受からなきゃ話にならん」

といきがってノー勉で受けたところ見事にあと1問のところで午前試験で落ちてしまいました。

運が悪かったと思いつつもあまりにも不甲斐ない結果で終わってしまったので流石に何か他の資格でもとっておこうと思い、色々検討した結果、今まで個人開発等で触ったことがありかつ弊社でも採用しているクラウドサービスであるAWSの資格試験は非常に馴染みが深く障壁が小さいと思い挑戦しようと思いました。

また普段使う機会のないサービスを学んだり体系的な知識を身につけるという面でも今後にとってプラスになるのではないかと思い受験しました。

勉強開始前のスペック

  • 個人開発で基本的なサービス(EC2,S3,Route53,RDS,IAM,CloudFront etc)は触ったことがある
  • 実務では前のインターン先で少し触ったくらい

CLF受験

CLFは巷では「簡単すぎて受ける価値が無い」などと言われていたりもしますが、SAAの勉強をいきなり開始するのは少し腰が重いと思って受けることにしまいした。結果的にCLFを最初に受けたことでCLF合格→SAA合格までのハードルがかなり低く感じて非常に良かったと思っています。

また、合格特典でSAA受験費用が半額になるのも非常に良いです。

勉強方法

AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー

AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー という参考書を1周して脳にある程度インデックスを貼ってからUdemyの模擬試験問題集をひたすら解きました。

このときに学んだことが土台となってSAAの勉強にもかなり生きた実感はあります。

結果としては797点(700点が合格ライン)で100点近く余裕を持って合格できました。

SAA受験

CLFと同様まずは参考書で体系的な知識をインプットしようと思い**AWS認定 ソリューションアーキテクト − アソシエイト教科書という参考書を1周しました。**

CLFの勉強で使用した参考書のSAA版である**AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイトよりも図を用いて丁寧に解説されていたので頭に入ってきやすかったです。しかし、これ1冊で合格するのはCLFと同様難しいのでUdemyの過去問をひたすら解きました。**

CLF合格後、通勤の時間で軽く勉強する程度でまったりと勉強していたのですが、8月下旬にSAA02→SAA03に改定されて試験範囲が広くなることを知り慌てて1週間前に申し込んで追い込みました。

勉強する時間が全然確保できなかったので正直厳しいと思いましたがなんとか合格できました。

改定される前に取得できて本当に良かったです。

資格を取得して思ったこと

資格を取得しても何か特別な能力が身についたり給料が急に上がったりはしませんが、AWS全般的に自身がついたと思います。今までは必要にかられて少し勉強する程度だったのでAWSへの苦手意識もあり、そこまで自信はなかったです。しかし、取得後はプライベートでも気楽にAWSを触れるくらいハードルが下がり、会社内で飛び交うAWS関連の会話も難なくついていけるようになりました。車の免許を取得しただけで日頃から運転しないと運転できないペーパードライバーであるようにAWSの資格も取得しただけでは形だけのものになってしまうのでしっかり手を動かしてAWSを触り続けることは非常に重要です。資格を取得するだけではさほど意味は成さないと思いますがAWSを触るきっかけとしては資格取得は悪くないと個人的に思いました。

今後も余裕があればDVAやSOAも取得して4冠を目指して行きたいと思います。

RaycastとDashで爆速でドキュメント検索する(IDEでも可能)

イベント開発の保坂です。

今回はランチャーアプリ「Raycast」とドキュメント検索アプリ「Dash」を組み合わせたら便利すぎたので、そちらの紹介をしたいと思います。
数クリックでできてしまうので是非試してみてください。

1. Raycastをインストールする

最近話題のランチャーアプリ「Raycast」をまだインストールしていない場合はインストールします。

https://www.raycast.com/
Raycastとは? という方はググってみると紹介されている素晴らしい記事がたくさんあるので、そちらを参考にしてみてください。


raycast

私は使い始めたばかりなのですが特に
  • Quicklinks
  • プラグインのAWS
  • プラグインのNotion
  • Calculator(計算機)
をよく使っている気がします。


2. Dashをインストールする

こちらもまだインストールしていない場合はインストール(購入)をします。

これはドキュメントを一元管理することができ、検索したい内容をいちいち、ググって、公式ページから該当箇所を見つけるという大体毎日するであろうタスクから解放してくれるアプリです。


Django Queryset

ググってみるとスニペット用のアプリと紹介されていますが、私は Dash で スニペット機能は使用していません。

Dash は有料アプリで約30$で購入できます。たまにアップグレード版が出て有料アップデートらしいのですが、公式サイトから最新版をダウンロードしてライセンスを使用してアクティベートしようとしたら私のラインセンスはver5で古いと言われ、勝手に新しいライセンスをダウンロードするリンクがメールで送られて来たので最新ver6を使用できています。


3. Raycast と Dash をつなげる


Raycast の extentions からDash のプラグインをダウンロードすることができます。


これで Raycast 上で dash と打ち込みそのプラグインをエンターしてあとは探したい語句を打ち込むだけです。


4. (おまけ)IDE と Dash をつなげる

Dash はIDEのプラグインにもよくあります。私は Jetbrain の IDE を使用しているのですが、マーケットプレイスからDashを入れます。

プラグインの使い方説明に Cmd-Shift-D (Mac)とあるので、エディター上でググりたい単語にマウスカーソルを合わせて、そのコマンドを打てば一発でそちらのドキュメントが開きます。

検索したい時は大抵開発中でエディターと向かい合っていると思うので、Raycastを使うよりさらに早く開けます。初めてやってみると速すぎて驚きます。



Web ページの動作検証のためのボットスクリプトを Windows 上で作る

この文書は、開発経験の無いチームがウェブアプリケーションの動作検証の責任を持つケースで、検証を簡単なプログラムで行うアプローチについての手法を解説しています。

Webアプリケーションの動作検証の際、手動で実行する以外にプログラムで検証すると便利です。開発者であればは検証コードを書くのは簡単ですが、開発経験の無い方はどこから始めたらいいかわからないと思いますので、比較的用意にスクリプトに入門できるように紹介します。OS は Windows を対象としています。

本記事で紹介しているようなプログラムによるリクエストは悪意の有無にかかわらず、不正アクセス禁止法での不正アクセスとみなされたり、電子計算機損壊等業務妨害罪等に問われる可能性があります。実際にリクエストを行う場合は、自社の管理する、許可されたサーバに対してのみ行うようにしてください。

HTTP の リクエスト・レスポンスの仕組みを知る

まずは、ウェブサーバと通信している HTTP のリクエストがどのようなものか知ることが必要です。この知識があいまいなままだとボットのスクリプトは書けません。

まずは、ウェブブラウザに搭載されている開発者ツールを使ってリクエストやレスポンスを観察するのが、良い勉強になります。

ウェブサーバに対して、

  • どの URL に対して
  • どのHTTP メソッドで (GET, POST, HEAD, PUT 等)
  • どのような HTTP ヘッダーで
    • cookie
    • referer
    • user-agent
  • どのようなリクエスト本文(body)で

以上を意識して、ブラウザの行っているリクエストをスクリプトで再現できれば、どのようなクライアントを使おうが、ウェブサーバからはブラウザでのリクエストと同じようにレスポンスが返ってきます。

Chrome のデベロッパーツールの使い方

  1. Google Chrome を起動してください。
  2. Shift + Ctrl + I を押してください。
    右側にデベロッパーツールが表示されます。
  3. デベローパーツールの上部のタブで、Network を選択してください。
  4. ブラウザの URL 欄に適当にページを打ち込み、ページを表示されてください。
  5. リクエスト一覧が表示されますので、適当なリクエストをクリックして選択してください。
  6. Headers にリクエストヘッダ、レスポンスヘッダ
    Payload にリクエスト本文
    Response にレスポンス本文
    が確認できます。
    特に、Headers のリクエストヘッダでどのようなヘッダを送っているか、確認してください。

Headers の中でも、cookie は特に注目してください。cookie の扱いはボット作成の中で最上位に重要な項目です。不安があれば、他のサイトや書籍を参考に学習してください。

また、 cookie の内容は認証情報を含むため、サイトのログインパスワードと同じぐらい重要な秘密情報です。安易にコピーは行わず、また絶対に他者に教えないようにしてください。ブラウザの cookie を格納している場所は安全ですが、他の場所にコピペすると漏洩リスクとなり、ログイン権限を奪われる危険性があります。

HTTPヘッダとクッキーの学習ができるサイト

HTTP ヘッダ、クッキーについての概要は、とほほ先生のサイト、わわわ先生のサイト、あと Wikipedia を読めば理解できます。

HTTPヘッダ

Cookie

ブラウザを手動で操作する以外での HTTP リクエストを行う方法

HTTP リクエストは、結局は特定の文字をサーバに送るだけですので、様々なクライアントで行うことができますが、よく使われるものを紹介します。

Postman

https://www.postman.com/
フリーの Windows クライアントがあります。GUI でリクエストを構築することができますし、スクリプトによる制御処理も書けます。有用なツールですが、最初は機能が多く複雑なため戸惑うかもしれません。

長所
  • GUI で完結する
  • 大量のテストリクエストの管理がしやすい
  • 署名の計算等、複雑な計算を伴う処理も行える。
短所
  • 複雑なため習得が難しい
  • 単純なリクエストを出すだけであれば冗長

curl

mac や linux を使う方には定番のコマンドラインツールです。Windows 10 からは標準でインストールされています。

長所
  • インストール済みなのですぐに使える
  • 単純なリクエストを1発出すだけなら一番適している
短所
  • 計算を伴う順次リクエストには向かない

Selenium や Puppeteer

プログラムで Chrome などのブラウザを実際に起動し、自動操作するための Selenium や Puppeteer といったツールがあります。

ブラウザを起動するため、ページ内で JavaScript を豊富に扱うページも自動操作し、検証することができます。

最近のウェブサイトは、React や Vue といった JavaScript を用いて表現するサイトが多くなってきており、その場合は Postman, curl, 後述するシンプルなスクリプトでは十分な検証ができない場合がありますので、 ページ内の JavaScript の動作検証が必要になる場合実際のブラウザを実行させる以外に無く、自動操作するには Selenium や Puppeteer を使うしかありません。

扱うには高度なプログラミング知識が必要ですので、今回は言及しません。

長所
  • ブラウザでの JavaScript の実行が必要であればこれ一択
  • 表示レイアウトの確認にも使える
短所
  • 実行環境の構築が難しくて、手間がかかる。
  • 他の、単純なリクエストを出す方式に比べると遅い。
  • 様々な要因により安定させて動作させるのは難しい。業務レベルで使うには高い技術が必要。

Rest Client ( .http)

ドットエイチティーティーピーファイルを作り、その記述したリクエストを簡易に何度も再現させることができます。VSCode や JetBrains エディタの機能として扱うことができ、記述が簡単で読みやすいため私は(当社内でも)かなり使います。

長所
  • 習得が容易
  • スクリプトの構文が容易で書きやすく読みやすい
  • スクリプトのチーム内共有が容易
  • レスポンスへの簡易的なテストを行うことができる
短所
  • 計算を伴う複雑な逐次処理はできない

プログラミング言語でスクリプトを組む

Python, PHP, Javascript, Ruby などで、既にある便利な HTTP クライアントライブラリを使ってスクリプトを組む方法です。
今回の記事ではこちらを今回紹介します。

長所
  • 条件分岐を含む複雑な制御処理が得意
  • 複数セッションによる並列リクエストを再現したい場合は一択
  • 完全無人での自動実行が容易
  • 書いたコードの再利用が容易
  • 処理結果の外部ツールへの連携が柔軟に行える
短所
  • 環境構築が手間
  • 単発のリクエストを検証したい場合は RestClient や Curl, Postman と比べても冗長

Windows に Python 実行環境をインストールする

Microsoft Store からの Python のインストール

Microsoft Store で Python パッケージが提供されるようになり、昔と比べて環境構築が楽になりました。

Microsoft が提供している、初心者向けの Python の開発ガイドが良くできています。この流れにそって進めれば問題なく進められますので、こちらも参考にしてください。

Microsoft Store のアプリを開き、 Python を検索して Python 3.10 をインストールします。

インストール後、念の為再起動を行い、その後コマンドプロンプトを起動して python と打ち込んで、 python が起動するか確かめてください。

Python 公式サイトからの Python のインストール

コマンドプロンプトで、 python と打ち込んで python が起動しないようであれば、Microsoft Store からインストールした Python はアンインストールし、 Python の公式サイトから Windows 版のインストーラパッケージをダウンロードしてインストールしてください。

その際、PATH を追加編集するかのオプションが表示されるので、チェックを入れてください。

https://www.python.org/downloads/

requests ライブラリのインストール

Python の インストールが完了したら、ウェブを操作するボットの作成に必須ともいえる、 requests ライブラリをインストールします。

コマンドプロンプトや PowerShell で、

python -m pip install requests

と入力すると、インストールが完了します。

Visual Studio Code のインストール

エディタは Visual Studio Code を使います。

Microsoft Store から Visual Studio Code を検索してインストールしてください。

プロジェクトフォルダの準備

Windows の、ドキュメントフォルダの下にtest-bot フォルダを作ってください。

VSCode を起動し、 File -> Open Folder で test-bot フォルダを開いてください。

フォルダを開いたら、左側のペインで右クリックし、 New File から first_bot.py というファイルを作ってください。

作成後、右下に「インタープリターを選択」と表示されているようであればクリックしてください。Microsoft Store からインストールした Python が、おすすめに表示されているので選択します。

右下に CRLF と表示されている箇所は、改行コードの設定が表示されています。CRLF は一般的ではないため、クリックして LF に変更しておきます。

Python の機能拡張のインストールがおすすめされると思いますので、Python, Pylance の機能拡張をインストールします。

スクリプトを書く

レスポンス本文を表示するだけのスクリプト

import requests
response = requests.get('https://www.torico-corp.com/')
print(response.text)

これは、 https://www.torico-corp.com/ のレスポンス本文を表示するだけの単純なプログラムです。
書いたら、右上の ▶ ボタンを押して、実行させてください。
出力結果がずらっと表示されます。

requests ライブラリについてのドキュメント

レスポンスの経過時間とステータスコードを表示するスクリプト

import requests
response = requests.get('https://www.torico-corp.com/')
print('経過時間 {}ms'.format(response.elapsed.microseconds / 1000))
print('ステータスコード {}'.format(response.status_code))

このスクリプトは、レスポンスの応答時間とステータスコードをコンソールに表示します。

Python に慣れてきたら、結果をファイルに記録するように改修することで、簡易的な負荷監視などに応用できます。

サイトの検索結果ページからを解析するスクリプト

Webサイトの検索ページにリクエストを行い、結果の HTML をパースしてコンソールに表示するスクリプトです。

HTMLをプログラムで扱えるように解析するために、 BeautifuSoup というライブラリをインストールします。

BeautifulSoup のインストール方法

コマンドプロンプトで

python -m pip install beautifulsoup4

でインストールできます。

BeautifulSoup の解説記事

コード

import requests
from bs4 import BeautifulSoup
response = requests.get('https://tech.torico-corp.com/search/?q=docker')
soup = BeautifulSoup(response.content, features='html.parser')

for h2 in soup.find_all('h2'):
a = h2.find('a')
if not a:
continue
print(a.text)
print(a['href'])

上記スクリプトは、TORICO の技術開発ブログを「docker」で検索し、出てきた記事のタイトルとリンクURL を表示しています。

メールアドレスとパスワードでウェブサイトにログインする

最後に、メールアドレスとパスワードでログインをするスクリプトの雛形を記載します。

requests ライブラリは、クッキー管理を行うことのできる Session というしくみがありますので、それを使います。

解説記事

検証するサイトによりますが、多くの場合は、ログイン時に「CSRFトークンの検証」と「Refererヘッダの検証
User-Agent が悪質なボットでないかの検証」を行っていると思いますので、そこを考慮してスクリプトを作れば、ログインが行えるはずです。

下記のような自動ログインのスクリプトは、必ずご自身が権限を持つサーバにのみ行うようにしてください。他者のサーバに行うと罪に問われる可能性があります。

URL 等は架空のものです。

import requests
from bs4 import BeautifulSoup

# session を作る
s = requests.session()
# User-Agent を設定する場合
s.headers['User-Agent'] = 'Tester Python Bot'

# ログインフォームを取得する
response = s.get('https://example.com/login-form/')

# HTTP のステータスコードに異常が無いか確認
response.raise_for_status()

# ログインフォームをパースする
soup = BeautifulSoup(response.content, features='html.parser')

# パースしたログインフォームから CSRF トークンを取得する
csrf_token = soup.find('input', {'name': 'csrftoken'})['value']

# ユーザー名とパスワードをいれてログインフォームを送信する。
response = s.post(
'https://example.com/login-form/',
data={
'email': 'tester@example.com',
'password': 'MY_AWESOME_PASSWORD',
# 先程取得した CSRF トークンを付与
'csrftoken': csrf_token
},
headers={
# Referer を付与
'Referer': 'https://example.com/login-form/',
})

# HTTP のステータスコードに異常が無いか確認
response.raise_for_status()

# ログイン後の URL が正しいものであるか確認
assert response.url == 'https://example.com/mypage/'

# この時点で、セッション s はログイン済みの状態なので、
# マイページ等をリクエストすることが可能
response = s.get('https://example.com/mypage/myprofile/')

そうだ、mysql8.0サーバーを構築してみよう

ども、お久しぶりです。

オンプレのインフラ構築を担当することが多い四斗邊です。

今回は社内の要望でmysql8.0サーバーを社内ネットワーク上に構築する!というのが目標です。

結構ありふれたネタだと思いますが、社内に向けた手順書のような形で残しておきたかったので今回記事しました。

PC構成


  • CPU intel i5-12400 6コア12スレッド 2.5GHz

  • メモリー CT2K32G4SFD832A メモリー32GB 1枚(レイテンシーは特に考えていない)

  • ベアボーンキット DeskMini B660

  • SSD WDS100T3X0E 1TB

これで10万円を切った構成になっています。
安くてそれなりに社内サーバーとしてはそこそこパワーがある構成にしてみました。
一番の特徴はなによりもベアボーンキットなのでコンパクトなのがいい。
個人的にはCPUはAMD派ですが、2022年8月上旬ではintelが安くてちょうどいいかんじでした。
家庭用なので消耗とか気になりますが、4年ぐらいは耐えてくれてると信じたい。

OSソフトウェア構成


OS ubuntu 22.04
DB mysql8.0.30

ubuntu以外も候補はありますが、構築経験があるのでこちらかなと。

mysqlインストール手順


*注意事項
手順の前にsshとかOS周りの設定は一通りしております。今回の手順はmysqlインストールに特化したものとご了承ください。

mysql-serverのインストール

$sudo apt install mysql-server

mysqlにログインする。

$sudo mysql
#ユーザー確認
mysql >select user,host from mysql.user;

インストールしているときに、すでにrootユーザーは作られているので、以下のコマンドでパスワードを改変する。hogeの部分は任意なパスワードに変える。

mysql > USE mysql; 
mysql >ALTER USER 'root'@'localhost' identified BY 'hoge';
一応権限の確認は以下で確認できる
mysql > show grants for 'root'@'localhost';

後々構築した後に気づいた点で、localhostになっているので、リモート時にはrootユーザーに入れないことがあった。

やっぱりここはrootユーザーのhost=%を作るに限る。(セキュアな面ではもうちょっとhost部分は制限したほうがいいかも)

mysql > CREATE USER 'root'@'%' IDENTIFIED BY 'hoge';
mysql > GRANT ALL ON *.* TO 'root'@'%';

これでリモート上でもrootで入れる。

文字のエンコードはutf-8に設定したかったので、my.cnfを以下のようにいじる。参考にしたURL↓

https://qiita.com/is0me/items/12629e3602ebb27c26a4

まずはmy.cnfの場所の特定。どうやら/etc/my.cnfが先で、次に/etc/mysql/my.cnfの順番で読み込まれるようだ。

mysql --help | grep my.cnf 
#以下結果 
order of preference,my.cnf, $MYSQL_TCP_PORT,
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

/etc/mysql/my.cnfの中身を見ると以下のような記載がありました。

!includedir /etc/mysql/conf.d/ 
!includedir /etc/mysql/mysql.conf.d/

/etc/mysql/conf.d/のディレクトリに入れると反映されるのでは?ということで、ここにmy.cnfを設置してみる。

保存するその前に、一旦、サーバー上でmysqlが止まっているか確認する。

mysqlが止まっているか以下でわかる。(すでに稼働している場合は周りに影響しないか注意してください。)

$sudo service mysql stop
#以下の内容を入れて/etc/mysql/conf.d/my.cnfに保存する。 
[mysqld]
character-set-server=utf8mb4
[mysql]
default-character-set=utf8mb4
[client]
default-character-set=utf8mb4
#更新したら以下でリスタートする。
service mysql restart

あとは、リモート上でも接続できるようにサーバー上でリッスンを設定する。今回は、mysqlのポート3306をリッスンさせる。

mysqlインストール時にすでにポートはリッスンしているので、bind-addressとmysqlx-bind-addressのアドレスを変更するようです。

/etc/mysql/mysql.conf.d/mysqld.cnf
#bind-address = 127.0.0.1
#mysqlx-bind-address = 127.0.0.1

更新したら以下でリスタートする。

service mysql restart

そうすると、自動的に全てのアドレスから全てのアドレス:3306でリッスンできる。

sudo ss -talpn 
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 151 *:3306 *:* users:(("mysqld",pid=3822,fd=23))
ただ、この設定は少し強引すぎる。

社内サーバー用とかで事前に外部からのアクセスを制限できているなど限定した場面で活用するのが望ましい。というか一応ufwも確認する。

sudo ufw allow 22 #ssh 
sudo ufw allow 3306 #mysql
sudo ufw enable
sudo ufw status numbered
To Action From -- ------ ----
[ 1] 22 ALLOW IN Anywhere
[ 2] 3306 ALLOW IN Anywhere
[ 3] 22 (v6) ALLOW IN Anywhere (v6)
[ 4] 3306 (v6) ALLOW IN Anywhere (v6)

これでmysqlとsshのみ通るようにポートは開けることが確認できた。

ここまでで一通りのmysqlサーバの完成となる。実際に自身のPC上で確認してみてください。

以下のコマンドで入れたら成功です。

(もちろんローカル上にもmysqlは入れてるよね?)

mysql -h XXXX.example.co.jp -u root -p
パスワードを入力:hoge

できましたかね?これであなたもmysqlサーバー構築者だ、おめでとう!

できない人は個別のトラブルシューティングに従って解決してください。

結構最低構成でできたはずなので、時間はかからないのかなと思っています。

みなさん試してみてください。

便利なfabricを使ってみる!

4月1日に新卒で入社したエンジニアの宮副です。
入社してすでに3ヶ月が過ぎました。
今回は、業務の中でもよく使われている「fabric」について書いていきます。

fabricとは

fabricはpythonのライブラリで、コマンドラインで関数を実行できるツールです。
さらに、SSH経由でシェルコマンドを実行することでもできます。
fabricをに定義することで、デプロイ時などで毎回打つ幾つものコマンドを省略することができるのでとても便利です。

実際にやってみる

実際にどういう風に使っているかを書いていきます。
まずはfabric(fabric3)をインストールします。

$pip3 install fabric3

次にfabric.py か fabfile/__initi__.py 内に関数を書くことでコマンドを実行できるようになります。
会社では fabfile/__init__.py 使っています。

def hello():
    print("Hello world!")

と書くと、

$fab hello

これで print() が実行されます。

では、次に少し応用してみます。

from fabric.api import local

def deploy_git():
    local("git add . && git commit -m 'commit message'")
    local("git push")

実行してみましょう。

$fab deploy_git

これでgitコマンドを打たなくても、pushすることができます。

また、

from fabric.api import local

def add():
        local("git add .")

def commit():
        local("git commit -m 'commit message'")

def push():
        local("git push")

def deploy_git():
    add()
        commit()         push()

このように構造化することで便利になります。

それぞれの環境にデプロイするときには、hostを指定してデプロイすることもできます。

from fabric.api import local

#開発環境
def dev():
    env.hosts = ['dev.example.com']

#本番環境
def production():
    env.hosts = ['www.example.com']

def deploy_env():
        #デプロイ処理
$fab dev deploy_env
#開発環境にデプロイ

$fab production deploy_env
#本番環境にデプロイ


__init__.py
に書いてるコマンドを見たいときには、

$fab -l

とするとfabコマンドを一覧で見ることができます。

まとめ

今回は業務のデプロイ作業で使っているfabricについて紹介しました。
入社して3ヶ月経ちましたが、まだまだ分からないことだらけの毎日です。
そんな僕でも、先輩エンジニアの方々に質問すれば丁寧に優しくわかりやすく教えていただけるので楽しく業務をすることができています。

コピペですぐ動く! Gmail をスプレッドシートに書き出す Google Apps スクリプト

あるメーリングリスト(Google グループ) に送信しているメールアドレスの一覧を作りたかったので今回のスクリプトを書きました。

普段 Gmail を使われている場合、Google Apps Script (GAS) を使うことでメールの処理をスクリプトで簡単に自動化することができます。

今回は、Gmail で受信したメールを検索し、検索結果を Google スプレッドシートに書き出す方法を紹介します。

ウェブ上のツールでスクリプトを少し書くだけで実現できます。メールを使う業務の自動化に応用できると思います。

1. Gmail の検索条件を作る

Gmail を開き、検索窓を使って対象のメールを絞り込みます。

to:label: などの演算子を活用して、絞り込んでください。

例えば、 mailinglist@example.com に向けて送信されている、 14日以内に受信したメールを絞り込む場合、

to:mailinglist@example.com newer_than:14d

として検索します。

その他の演算子はこちらに紹介があります。

Gmail で使用できる検索演算子 - Gmail ヘルプ

作成した検索条件は記録しておきます。

2. 書き出し先のスプレッドシートを作る

Google スプレッドシートを開きます。

https://docs.google.com/spreadsheets/

「新しいスプレッドシートを作成」の「空白」を選択します。

作成されたスプレッドシートのURL を確認します。

https://docs.google.com/spreadsheets/d/<ここの部分>/edit#gid=0

上記の、英語の乱数部分がスプレッドシートのIDです。これを記録しておきます。

3. Google Apps Script を作る

https://script.google.com/ を開きます。

「新しいプロジェクト」をクリックします。

「無題のプロジェクト」となっている箇所をクリックし、「メールをスプレッドシートに書き出し」など、適当に変更します。

スクリプトの内容は、下記内容をそのままコピペします。

function exportGmails() {
var book = SpreadsheetApp.openById('<ここにスプレッドシートIDを記入>');

var criteria = '<ここにGmail検索条件を記入>';
var threads = GmailApp.search(criteria);

var sheet = book.getActiveSheet();
sheet.getRange(1, 1).setValue('日付');
sheet.getRange(1, 2).setValue('宛先');
sheet.getRange(1, 3).setValue('From');
sheet.getRange(1, 4).setValue('ReplyTo');
sheet.getRange(1, 5).setValue('件名');

for (var i = 0; i < threads.length; i++) {
messages = threads[i].getMessages();
message = messages[0];
console.log(message.getFrom());
rowNumber = i + 2;
sheet.getRange(rowNumber, 1).setValue(message.getDate());
sheet.getRange(rowNumber, 2).setValue(message.getTo());
sheet.getRange(rowNumber, 3).setValue(message.getFrom());
sheet.getRange(rowNumber, 4).setValue(message.getReplyTo());
sheet.getRange(rowNumber, 5).setValue(message.getSubject());
}
}

<ここにスプレッドシートIDを記入> の箇所を、2で作成した スプレッドシートのURLに含まれるIDに書き換えます。

<ここにGmail検索条件を記入> の箇所を、1で作成した Gmailの検索条件に書き換えます。

保存ボタンを押して、実行を押します。

初回起動時は、「承認が必要です」というダイアログが表示されるので、「権限を確認」をクリック。

個人用の Gmail の場合、「このアプリは Google で確認されていません」となるので、「詳細」をクリックして 「(安全ではないページ)に移動」をクリック。
(企業の Google Apps の場合、この警告は出ません)

許可ダイアログで「許可」をクリック

するするっとコードが実行されて、スプレッドシートに書き込まれます。

スプレッドシートに書き出す項目を変更する場合、コードを修正してください。

コード中に、message.getDate(), message.getTo() などのメソッドでメール内の属性を取得していますが、その他の属性も書き出すことができます。メールオブジェクトのメソッドのリファレンスはここにありますので参考にしてください。

Class GmailMessage | Apps Script | Google Developers

Ubuntu22 に MicroK8s で Kubernetes 環境を構築し、その中で Rancher を起動する

今まで(2021年頃まで) は、社内サーバの Kubernetes 環境を作る際は、 Rancher を Docker で起動し、その中の RKE で Kubernetes クラスタを構築していました。

ところが、それだと OS のアップデートがあったりした時など、年一回ぐらいのペースでトラブルがあり、環境が再構築不能になってしまっていました。

Rancher + RKE で Kubernetes 環境を作っている場合、トラブルの原因を追うのが非常に難しくて、原因まで解明して解決できたことはありません。

今回は、 Kubernetes 環境は Ubuntu の MicroK8s で起動し、その K8s の中で、 Deployment として Rancher を起動するようにしました。

試してみた所、なかなか快適だったため、今後もこのパターンは使っていこうと思います。

OS は Ubutntu 22.04 で、ノードはシングルノード構成です。やはり OS が Ubutnu の場合は MicroK8s が簡単で安定しており、Ingress なども一発で有効化できるため、セットアップは楽でした。

1. MicroK8s の セットアップ

1-1. インストール

sudo snap install microk8s --classic

1-2. ユーザーに権限を付与する

sudo usermod -a -G microk8s ubuntu
sudo chown -f -R ubuntu ~/.kube
newgrp microk8s

1-3. DNS, Ingress の有効化

microk8s enable dns ingress

1-4. ダッシュボードを使う場合

Rancher が起動したらダッシュボードは不要だと思いますが、Rancher 起動前の確認用として重宝します。

microk8s enable dashboard

Kubernetes のノード上で

microk8s kubectl port-forward -n kube-system service/kubernetes-dashboard --address 0.0.0.0 31443:443

してから、https://<your-host>:31443/ を見る

2. kubeconfig の取得

microk8s config

コピペして、 Mac の .kube/config-<Config名> にコピーしておく

3. namespace の作成

※ Macで実行

#!/usr/bin/env zsh

export KUBECONFIG=${HOME}/.kube/config-<Config名>

kubectl create namespace <ネームスペース>

4. secrets の作成

SSL証明書 (wildcard.example.com.key, wildcard.example.com.crt) を mac のディレクトリに用意して、

※ Macで実行

#!/usr/bin/env zsh

export KUBECONFIG=${HOME}/.kube/config-<Config名>

kubectl -n <ネームスペース> create secret tls tls-certificate \
--key <wildcard.example.com.key> \
--cert <wildcard.example.com.crt>

5. Rancher のインストール

サーバに /data/rancher ディレクトリを作っておく

deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-awesome-rancher-deployment
namespace: <ネームスペース>
spec:
replicas: 1
selector:
matchLabels:
app: my-awesome-rancher
template:
metadata:
labels:
app: my-awesome-rancher
spec:
containers:
- name: my-awesome-rancher
image: rancher/rancher:v2.6-head
imagePullPolicy: Always
ports:
- containerPort: 80

volumeMounts:
- name: data-rancher
mountPath: /var/lib/rancher

imagePullSecrets:
- name: ecr-credeintial

volumes:
- name: data-rancher
hostPath:
path: /data/rancher

service.yml

apiVersion: v1
kind: Service
metadata:
  name: my-awesome-rancher-service
namespace: <ネームスペース>
spec:
type: NodePort
ports:
- port: 80
protocol: TCP
targetPort: 80
name: my-awesome-rancher-http
selector:
app: my-awesome-rancher

ingress.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-awesome-rancher-ingress
namespace: <ネームスペース>
spec:
tls:
- hosts:
- my-awesome-rancher.example.com
secretName: tls-certificate
rules:
- host: my-awesome-rancher.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-awesome-rancher-service
port:
number: 80

※ mac で実行

#!/usr/bin/env zsh

export KUBECONFIG=${HOME}/.kube/config-<Config名>

kubectl apply -f deployment.yml
kubectl apply -f service.yml
kubectl apply -f ingress.yml

6. Rancher の ブートストラップパスワードの取得

Rancher を起動すると、「ブートストラップパスワード」が発行され、ログに表示されます。

今回は Kubernetes の Pod として起動しているため、Pod のログを grep します。

 ※ Macで実行

#!/usr/bin/env zsh

export KUBECONFIG=${HOME}/.kube/config-<Config名>

pods=( $(kubectl get pod -n <ネームスペース> | egrep -o "my-awesome-rancher-deployment-[a-zA-Z0-9-]+") )

for pod in "${pods[@]}" ; do
kubectl logs -n <ネームスペース> ${pod} | grep "Bootstrap Password:"
done

7. ブラウザから Rancher へのログイン

my-awesome-rancher.example.com (仮のドメインです) というドメインで Rancher が起動しているはずなので、DNS を設定してからブラウザでアクセスします。

Bootstrap Password の入力を求められるので、先程取得したものを入力します。

ローカルで起動している MicroK8s のシングルノードクラスタを自動的に認識し、管理できるようになります。

付録

kubernetes の secret へ、AWS の EKS のログイントークンを登録する Python スクリプト

当社は、Docker イメージリポジトリは AWS ECR を使っています。
ローカルPCの ~/.aws/credentials の認証情報を元に、 Kubernetes の Secret を作るスクリプトを紹介します。

#!/usr/bin/env python3

import subprocess
import re
import sys

namespace = '<ネームスペース>'
secret_name = 'ecr-credeintial'
aws_region = 'ap-northeast-1'
docker_server = 'https://<AWS-ID>.dkr.ecr.ap-northeast-1.amazonaws.com'


def main():
output = subprocess.check_output([
'/usr/bin/aws', 'ecr', 'get-login',
'--no-include-email', '--region', aws_region,
]).decode()
words = output.split()
username = words[words.index('-u') + 1]
password = words[words.index('-p') + 1]

// 既に作成済みの secret を消す
command = [
// kubectl の実行環境に合わせて調整してください
'microk8s', 'kubectl', '-n', namespace, 'delete', 'secret', secret_name]
subprocess.run(command)

// secret を再登録する
command = [
'microk8s', 'kubectl', '-n', namespace, 'create', 'secret',
'docker-registry', secret_name,
f'--docker-username={username}',
f'--docker-password={password}',
f'--docker-server={docker_server}'
]
subprocess.run(command)


if __name__ == '__main__':
main()

ジュニアエンジニアの業務内容

エンジニアの高津です。
今回はこの1ヶ月でどのような業務を行ったのか紹介していきたいと思います。
TORICOにエンジニアとして入社を検討している人に少しでも参考になれば幸いです。

主な業務内容

自分はコーマス開発部で、漫画全巻ドットコムの開発をメインでやっています。

簡単なバグ(UI)の修正漫画全巻ドットコムのリニューアルの大きく2つに分けられます。

簡単なバグ(UI)の修正

こちらは数時間で終わるような簡単なUIの修正(改修)で入社して3日後にはプルリクエストを出していました。

  • アイコン(font-awesome)が正しく表示出来るようにする
  • 個人情報同意フォームの改修
  • 電話番号記入欄のに数字が4文字入るようにする
    などの業務を行いました。

漫画全巻ドットコムのリニューアル

漫画全巻ドットコムは10年以上続く歴史のあるサービスで最初はPHPで作られていました。
メンテナンス性に問題があったのでDjango+Nuxt.jsにリプレイスしています。
今回自分は電子新着ページ電子割引ページをリニューアルしました。(ブログを書いている時点で実装は終わっていますがレビューが終わってないので本番にはまだ反映されていません)
Nuxt(フロントエンド)は先輩方が作ってくれた雛形を軽く修正して利用出来るのでDjnago(バックエンド)の実装がメインでした。
今回はその中でも難しかったポイントをいくつか列挙したいと思います。

キャッシュを効かす

同じ値を取得して返すだけなのに毎回SQLを叩くのは無駄なのでkye-value型のNoSQLであるredius(メモリ)に一定時間値を保管し、値がキャッシュされていなければSQL等を叩く処理を行います。(keyは引数、valueは返り値で保存)
ページ単位(view)単位でキャッシュする方法とクラスメソッド単位でキャッシュする方法の2パターンあります。
カテゴリー別の作品数を取得する処理はページ間(異なるurl)でも共通したしょりなのでクラスメソッド単位でキャッシュする必要があり、少々手こずりました。

SQLの実行回数(IO)を極力少なくしパフォーマンスをあげる

今回一番苦戦しましたポイントです。
ただ実装するだけであればすぐ終わったのですが、最初の実装ではSQLを12回叩いてしまっていたのでリファクタリングする必要がありました。(俗に言うN+1問題が発生していました)
こちらはやり方を先輩方にご教示頂き、MySQLにだけサポートされているconcat関数をraw_queryで使い1回で取得することに成功しました。
実際には以下のようなSQLに落ち着きました。

select GROUP_CONCAT(sample_id) AS ids, group_type from
dtb_sample WHERE aggregate_type=
'%s' AND product_type = 2
group by group_type ORDER BY sort_key;

テスト

TORICOの開発ではただ動くものを作るだけでなくその後の保守運用のことも考慮して単体テスト、統合テストも書くように徹底されています。
特にDB設計が少々複雑なこともありテストデータを作るところはかなり苦戦しました。

具体的には以下のようなことをテストしました。

  • 各URLにgetして正しい値やstatusが返ってくるか
  • 各メソッドのすべての条件分岐において正しく動作するかどうか
これらのテストを書くことでテストのしずらいメソッドが見つかり、それをリファクタリングすることで保守性の高いコードに改善出来ます。

また、仕様が分からない人がみても理解できるようにWhy「なぜこの処理を書くのか?」を極力書くように意識しました。

まとめ

如何でしたでしょうか?

今現在23卒のエントリーを受け付けています。
少しでも興味を持ってくれた人は是非応募して頂けると幸いです。

AWS RDSで大量のデータを削除する時等に、性能劣化を避けるために確認すべき項目(クレジット残高)

RDS で、大量のIO を伴う処理を行うと、処理途中で性能が大きく劣化することがあります。
不要になった大量の過去データをバッチで削除する時によく発生します。

これは、ストレージへの IO を規定量より高い頻度で行った時に減少するクレジットがあり、それが 0 になった時、パフォーマンスに制限がかかってしまうためです。

制限のかかった状態では通常通りのサービス運用はできなくなってしまうため、過去データ削除などの高負荷のバッチは、RDSのモニタリングページを見ながら注意深く実施する必要があります。

今回は、パフォーマンス低下を避けるために確認すべき RDS クレジットのメトリクスについて書きます。

各メトリクスの詳細は、AWS の公式ドキュメントに詳細な解説があります。 

高負荷な処理を行う際に確認すべきメトリクス

EBS Byte Balance

AWS のドキュメントによると、「RDS データベースのバーストバケットに残っているスループットクレジットの割合。」とのこと。データ転送量で減少していくのでしょうか。重い SQL を実行することで減ることがあります。

0になるとパフォーマンスが大幅に劣化します。

クレジットを消費するような SQL を実行しなければ、自動的に回復します。

EBS IO Balance

AWSドキュメントによると「RDS データベースのバーストバケットに残っている I/O クレジットの割合。」とのこと。広範囲の DELETE 文など、 IO が多く発生する SQLを実行するとどんどん減っていき、0になるとパフォーマンスが大幅に劣化します。クレジットを消費するような SQL を実行しなければ、自動的に回復します。

Burst Balance

AWSドキュメントによると「汎用 SSD (gp2) のバーストバケット I/O クレジットの利用可能パーセント。」プロビジョンド IOPS の RDSには項目がありません。GP2 ストレージの場合に、広範囲の DELETE 文など、 IO が多く発生する(IOバーストがされる) SQLを実行すると減っていきます。

CPU クレジット残高

T系インスタンスの場合にあります。CPUを多く使う(CPUバーストがされる)処理を行うと減っていき、0になるとパフォーマンスが大幅に劣化します。T系のEC2とお使いであれば、おなじみの項目ですね。

バイナリログのディスク使用状況とリードレプリカのレプリケーション遅延

リードレプリカをマスターより低い性能で運用している場合、マスターで行った処理を同じ速度で処理することができず、レプリケーション遅延が発生することがあります。

この時、リードレプリカが処理できないバイナリログはマスターの RDS に蓄積されるため、バイナリログのサイズが溜まっていき、リードレプリカの遅延もどんどん大きくなります。

解消させるにはマスターの処理のペースをリードレプリカに合わせて減らすしかありません。

状況に気づかずに大きな遅延とバイナリログができてしまった場合、遅いリードレプリカの処理を待つより、一度リードレプリカを削除し、新たに作り直したほうが時間短縮になる場合があります。

まとめ: 高負荷な SQL を発行する時に気をつけること

クレジット消費で一番やりがちなのは DELETE 文で多くのレコードを消そうとした場合です。また、その DELETE で変更されたストレージを最適化させるための OPTIMIZE TABLE でも多くのクレジットが消費されることがあります。

DELETE を行う場合、量にもよりますが、一発で済まそうとせず、範囲を絞って何度か実行するような SQLでメンテナンスしたほうがトラブルを避けられます。また、範囲指定もインデックスを使うようにし、意図しない広範囲のロックを避ける必要があります。

OPTIMIZE TABLE は範囲を絞ることはできないため、メトリクスを監視しながら、クレジットが 50% を切るようであれば停止を検討したほうが良いでしょう。

OPTIMIZE TABLE に限らず、10分以上かかるSQL の場合は、AWSコンソールから上記 EBS Byte BalanceEBS IO BalanceBurst BalanceCPU クレジット残高バイナリログのディスク使用量またリードレプリカの遅延 のメトリクスを常に監視し、クレジットの使い切りを発生させないようにしてください。

TORICOの品質管理業務 2. 検証に必要となる知識


こんにちは、品質管理チーム (QCチーム) の渡辺です。
ちょっと遡りますが、わたしがQCチームに初めて配属時とこれまでのお話をしましょう。

どこにでもシステムは組み込まれている

 わたしはこれまでは運営業務のお仕事が中心でした。
リアル店舗では接客、商品仕入れ、コーナー作り、特典作成、Web店舗では通信販売、電子書籍販売、バナー、サイトページ、企画などのページ作成、またカスタマー業務と幅広く携わってきました。
 お勧めの作品がお客様の目に留めてもらうために、工夫を凝らして試行錯誤して、作品の売行きが好転すると、次回も頑張ろうと意欲が湧くものでした。
そのために、システム開発者に協力をお願いし、サイトのレイアウトや企画を伝えては、変更やシステム開発をしてもらっていました。
漫画のコマをページに載せたり、スクロールしても付いてくるキャラ画像を設置してもらったり、特典のダウンロード機能を付けてもらったりと、工夫を凝らしたシステムを作ってもらい導入してもらいました。
現在も漫画全巻ドットコムサイトで継続されている全力推し宣言もその一環でした。数年後にお勧め作品がすべてアニメ化になった時は、心の中でガッツポーズしたものです。
わたし自身のWeb業務は、HTMLタグで色や文字を変更したり、時にはサイトのプログラムリニューアルで当時人気のBootstrapに切り替える作業や自社レジ作成のお手伝いをしていました。そんな中で、Web初心者よりは“Webを理解している”と思ってました。

 ご興味あればこちらから ⇒ 漫画全巻 全力推し宣言ページ

あの頃のWeb知識は初心者と一寸法師の背比べ

昨年10月にQCチームが立ち上がり、配属されたわたしは、今までの経験が活かせると大いに喜びました。
なぜかというと、業務内容が「デバッグ作業」という、サイトの中でお客様が検索や購入する操作をセッションごとにテストいき、操作中に不具合は出現しないか、レイアウトは崩れていないか、バグ発見次第に開発者へ報告する、ということだったからです。
また「開発中システムのテスト検証」もお客様にみせるサイトに関わる事なので、どちらもいままでの経験が役立っています。
そしてもう一つのミッションが「セキュリティ強化対策の検証」です。
この3つの業務を通して、システム開発者のお話を聞く機会も増えてきて、ようやく、わたしの持つWeb知識があまりにも少なくまた基礎が無いことが気づきました。開発者では良く会話の中に登場するAPI、プロトコル、AWSなど、単語の意味が分からない。いまや小学生から習う“インターネットの仕組み”も理解していませんでした。

Web知識は本から取得するのも一つの手


 そんな時に上司より良い教材を提供された、SB Creative刊『イラスト図解式 この一冊で全部わかるWeb技術の基本を読みました。
インターネットの基礎知識からセキュリティの脆弱性の脅威まで幅広く扱っていて、単語も調べられるので、とてもに役立っており、いまでも読んでいます。

本の詳細は出版社サイトへ⇒『 イラスト図解式 この一冊で全部わかるWeb技術の基本 』

読んでいくとスマートフォンでおなじみの「アプリ」画面は、chromeの画面と同じ「ブラウザ」であるなど、目から鱗なお話もあり、面白いです。
まだまだ、初心者に毛が生えたレベルのわたしですが、ここからもっと知識を蓄えて開発者たちの会話が分かるように努力していきます。

TORICOの品質管理業務 1. システムの動作検証の流れ



こんにちは、品質管理チーム (QCチーム) の渡辺です。
QCチームのお仕事の中に『システム動作の検証』というお仕事があるので、少しお話をしようと思います。

検証とは?

検証とは、2つの意味があります。
一つは、仮説が正しことを証明するために調べる事、もう一つは、しっかり調べ事実確認する事です。
わたしたちのお仕事の検証は前者の[仮説が正しことを証明するために調べる事]です。
どの部分で検証するかというと、システム開発担当が、構築したプログラムをサイトの本番環境(お客様が閲覧する環境)へ反映する前にわたしたちが検証を行っています。
ここでは検証の環境に応じて、テスト環境ではテスト検証、本番環境では本番検証と使い分けしておきます。
【参照】実用日本語表現辞典【検証】

完成されたシステムでも仮説?

開発者は依頼された仕組み(システム)をプログラミングします。この時の環境はローカル環境(開発者のパソコン内)だったり、開発者同士の共有環境だったりと、外部には絶対に流出しない環境で作成され、完成した段階で、本番環境にもっとも近いテスト環境に反映されます。
開発者の環境では完成しているのだから、もうすでに仮説ではなく定説になるのではと思われるかもしれません。
しかし、ここで問題なのが、正しく動作するという『証明』が開発者の環境下のみというところにあります。
わたしたちのお客様はいろんな端末を使って、サイトに訪れてくれます。
そのお客様が開発者と同じ端末で操作が行われることはそう多くないのです。
そのため、開発者の環境下の端末だけでは、完全には『証明』が出来ないのです。

QCチーム作業が始まる

ここからが、わたしたちQCチームの作業になります。
テスト環境に反映されたシステムをテスト検証します。
テスト項目書に「〇〇をクリックすると◎◎が開く」とあれば、そちらに沿って正しく動作をするかを調べます。
システムが正しく動作していれば「結果=◎◎が開く」となります。こちらで1項目クリアになります。
一見、すぐに終わるのでは?と思われがちですが、端末やブラウザを変えて、同じテスト項目を繰り返し行っているので時間がかかります。

端末は複数台を常時稼働

主に使用している端末はパソコン、スマートフォンのiPhone、android、ブラウザは、edge、chrome、firefox、safariにて行っています。
ボタンを1つ押してページが切り替わるという単純なテスト検証でも少ないても6回は行っていることになります。
また操作する人が変わると同じ端末であっても、なぜか結果が変わることもしばしばあるので、できるだけ数人で行うようにしています。

気になる事はとことん

そして、少しでも気になることがあれば、同じ操作を繰り返し行い、これは正しく動作していると納得いくまで行います。
何か引っかかる事がある場合、本番反映された時にそれが致命的なことになりかねないので、原因が判明するまでは検証を繰り返します。
どんな操作を用いても正しく動作することを「証明」するには、何度も繰り返し検証をしてみるということがとても重要なことなのです。

最後は本番環境

テスト検証にて、動作確認が終わったら、本番に反映されます。
テスト環境が本番環境に一番近いとはいえ、本番環境においても動作を『証明』しなければなりません。
また、稼働中のサイトなので、お客様がいつシステムを使用するか分かりません。
そのため、速やかに追加したシステムが正常に動作をするか、既存システムも動作しているかを素早く検証する必要があります。
そして、全てのシステム動作の検証が終わり、ようやく追加プログラムが正しい事を『証明』できたことになるのです。

以上、QCチームの『システム動作の検証』について、掻い摘んで解説してきましたが、いかがだったでしょうか?
この記事を通して、少しでもわたしたちのお仕事に興味を持っていただけたら、幸いです。

Flutter riverpod + hooks_riverpod の基本的な状態管理の使い方を Vuex (typed-vuex/vuex-module-decorators)と比較して紹介

当社 TORICO ではモバイルアプリ開発のフレームワークに Flutter を採用し、ウェブのフロントエンドのフレームワークとしては Nuxt を採用しています。

普段 Nuxt で開発している方が Flutter での開発を始める際、Flutter での状態管理フレームワークとして、riverpod + hooks_riverpod を使う場合、基本的な使い方を Vuex と比較すると理解が早まります。

状態管理とは

フロントエンド開発の際、「状態管理」という言葉がよく使われます。この「状態」という言葉、最初聞いた時は「この処理はステートフルだ」という言い回しでよく使う「ステート」と同じものだと思っていたのですが、実際はそれより狭い意味であり、「変数の変化をUIの再描画にリアクティブに伝える仕組み」ぐらいに思っておくと良いと思います。

今回の例では、数字の配列から平均値を求めてUIに表示していますが、「配列に値を追加する」という処理を書いただけ(実行するだけ)で、平均値の再計算と必要なUIの再描画が自動で行われます。この一連の自動処理を、「状態管理」と呼ぶと思ってください。

Nuxt + Vuex のカウンターアプリ

Githubでにソースコードを公開しています。

まずは、Nuxt + Vuex でカウンターアプリを作ってみます。上のボタンを押すと、カウンターが増え、下のボタンを押すと、そのカウントを Array に追加します。ついでに Array の平均値も表示するようになっています。

Vuex を TypeScript で書く場合、サポートライブラリとして nuxt-typed-vuex を使う方法と vuex-module-decorators を使う方法がありますが、今回はその両方の比較も兼ねて、両方のパターンで書いてみました。

Nuxt typed-vuex で書いたストア

Github で見る

import {getterTree, mutationTree, actionTree} from 'typed-vuex'

export const state = () => ({
// カウンター
count: 0 as number,
// カウンターの値を追加するリスト
countList: [] as number[]
})

export type RootState = ReturnType<typeof state>

export const getters = getterTree(state, {
// countList の平均値を求める
average: (state) => state.countList.length
? state.countList.reduce((p: number, c: number) => p + c, 0) / state.countList.length
: 0
})

export const mutations = mutationTree(state, {
// カウンターを増加
countUp(state) {
state.count += 1
},
// カウンターリストに追加する
appendCount(state, value: number) {
// nuxt の場合再代入の必要なし。push で再描画される。
state.countList.push(value)
}
})

export const actions = actionTree(
{state, getters, mutations},
{
// 現在のカウンターの値を countList に追加するアクション
async addToCountList({commit, dispatch, getters, state}) {
commit('appendCount', state.count)
}
}
)

Nuxt vuex-module-decorators で書いたストア

Github で見る

import {Module, VuexModule, Mutation, Action} from 'vuex-module-decorators'

@Module({
name: 'counter',
stateFactory: true,
namespaced: true
})
export default class extends VuexModule {
// カウンター
count: number = 0

// カウンターの値を追加するリスト
countList: number[] = []

// countList の平均値を求める
get average() {
return this.countList.length
? this.countList.reduce((p: number, c: number) => p + c, 0) / this.countList.length
: 0
}

// カウンターを増加
@Mutation
countUp() {
this.count += 1
}

// カウンターリストに追加する
@Mutation
appendCount(value: number) {
// vuex の場合再代入の必要なし。push で再描画される。
this.countList.push(value)
}

// 現在のカウンターの値を countList に追加するアクション
@Action({rawError: true})
addToCountList() {
this.appendCount(this.count)
}
}

両方のコードはまったく同じ動作をします。

ポイントとして、 appendCount のミューテーションですが、countList に .push で値を追加しているだけです。

リアクティブに状態の更新を UI に伝えるために、新しい Array を作って countList に代入しなくて大丈夫か、という感じはしますが、vuex の場合は Array や Object がステートに登録された場合、Observer というクラスを介して操作され、内容の変更もリアクティブに再描画されるようになりますので、これで大丈夫です。

Observerは、一部の Array のメソッドが使えなかったり、デバッグ時に値が直接見にくいなどの弊害もあるので、個人的には、この挙動はお節介すぎる気がしますが、理解して使えばコードを短く書けるため、上手に使いましょう。

Flutter + riverpod + hooks_riverpod で書いた場合

これと同様のアプリを Flutter + Riverpod + riverpod hooksで書いています。

Github で見る

counter_controller.dart

Githubで見る

import 'package:hooks_riverpod/hooks_riverpod.dart';

// カウンター
final countState = StateProvider<int>((ref) => 0);

// カウンターの値を追加するリスト
final countListState = StateProvider<List<int>>((ref) => []);

// countListState の平均値を求める
final averageProvider = Provider<double>((ref) {
final productList = ref.watch(countListState);
return productList.isNotEmpty
? productList.fold<int>(0, (v, e) => v + e) / productList.length
: 0.0;
});

final counterController =
Provider.autoDispose((ref) => CounterController(ref.read));

class CounterController {
final Reader _read;

CounterController(this._read);

// カウンターを増加
void countUp() {
// この update は、以下と同じ動作をする
// _read(countState.notifier).state = _read(countState) + 1;
_read(countState.notifier).update((s) => s + 1);
}

// 現在のカウンターの値を countList に追加するアクション
void addToCountList() {
_read(countListState.notifier).update((s) => [...s, _read(countState)]);
}
}

ほぼ同じ感覚で書けています。

vuex store でいう state は、StateProvider を使い、getter は Provider を使って書けます。

mutation は、 StateProvider に対し、 _read(myStateProvider.notifier).state = xxx とします。
これにより、状態の変更が StateProvider を Watch しているウィジェットに伝わり、再描画を行います。

action で書くようなロジックは、それらのメソッドを持つクラス(上記例では CounterController )を作り、そのインスタンスを Provider として作っておくのが良いと思います。 WidgetRef にアクセスさえできればどこに書いても動くのですが、vuex を真似て、StateProvider 等が書いてあるファイル中に一緒にコントローラークラスとして作っておくと、Flutter のプロジェクトも Nuxt のプロジェクトも同じような感覚で修正できるので、楽になるのではないでしょうか。

UI 側のコード(main.dart)の抜粋

Github で見る

class CounterWidget extends HookConsumerWidget {
const CounterWidget({Key? key}) : super(key: key);

@override
Widget build(BuildContext context, WidgetRef ref) {
final count = ref.watch(countState);

return Column(children: [
Text(count.toString(), style: const TextStyle(fontSize: 48)),
ElevatedButton(
style: ElevatedButton.styleFrom(
shape: const StadiumBorder(),
),
onPressed: () {
ref.read(counterController).countUp();
},
child: const Text('CountUp'))
]);
}
}

HookConsumerWidget を継承したウィジェットを作り、その中で ref.watch すると、その変数が更新された時に UI が再描画されます。

これからアプリケーションエンジニア(プログラマ) になるための準備

この記事は、株式会社TORICO Advent Calendar 2021 12/21 の記事です。

他社の方と話をした際、お子さんがアプリケーションエンジニアに興味があるという話を聞いたので、これからアプリケーションエンジニアになる人に向けての記事を書こうと思いました。

この記事の中にはエンジニアという言葉が何度も出てきますが、機械・工学のエンジニアのことではなく、コードを書いて機械を自動的に動かす人のことです。区別するために、なるべくアプリケーションエンジニアという表現をするようにしています。

アプリケーションエンジニア(プログラマ)とはどんな仕事か

エンジニアの業態は、大きく分けて、自社開発と受託開発があります。

自社開発とは

サービスの提供と開発を同じ会社で行っている場合がこのケースに当てはまります。社会人経験の少ない方は、おそらくサービス提供会社がアプリケーション開発も行っている印象を持たれる方は多いかもしれませんが、売上を上げるサービスをすべて自社開発している会社は、みなさんが考えているよりずっと少ないです。

サービスを自社で開発する会社は、企画を実現させるための工程が少ないため、スピード感のあるサービス開発が行えます。トライアル&エラーの手数も多く、開発技術がサービスに強く反映されます。

会社規模によっては十分なエンジニアチームが作れていない場合もあり、エンジニア人数が少ない場合、知識・技術に偏りが出たり新技術をうまく採用できていない場合があるため、求人応募する際は十分にチーム構成を調べたほうが良いでしょう。最新技術を十分に取り込んでいても、自分の求める開発チームの理想形とマッチしていない場合もあります。会社の技術ブログを見て自分にマッチしているかは事前によく調べておいてください。

会社の中の開発チームは、単純なプログラミング以外でも技術全般を広く担当する場合が多いため、ユーザー行動の解析だったり業務会計データの集計・整形だったり、社内LANの構築やグループウェアのメンテナンス、デザインや動画編集なども頼まれる場合があります。会社規模が小さいほど広い担当範囲を求められます。

そもそも自社開発の場合、会社組織がエンジニアに求めることが、「プログラムを書く」ではなく「業務課題に対して技術で貢献する」である場合が多いです。会社によると思いますが、私が今まで経験した会社はすべてそうでした。仕事をする上で、「プログラムを書く」かどうかはあまり関係無く、「新しいサービスをできるだけ多くのお客様に使ってほしい」といった業務課題があり、エンジニアはサービスの実態を作ることができるのでその分野で貢献します。ただ作るだけではなく、他メンバーとゴールやKPIを共有し、どうすれば合理的にその目標を達成できるか考えながら仕事をしていきます。

そのため、自社開発のエンジニアはビジネス的な観点も必要とされますし、ビジネス成果がエンジニアの評価とされる場合も多くあります。自分が書いたコードがお客様や会社の売上に直接影響することを実感できますし、誤って不具合を含んだコードをリリースしてしまった際は、お客様や他のメンバーから辛辣な苦情を受けることになります。

求人応募者にはエンジニアとしての即戦力を求めるため、受託開発より基準は高くなると思います。採用面接時には技術的な質問を多くされ、即戦力でなさそうだったり、業務水準に達するまでの成長時間が長くかかりそうだと判断されれば採用見送りとなります。中途採用の場合は、未経験だと採用は厳しいでしょう。未経験の場合は、業務以外の開発成果(ブログ・ポートフォリオサイト・オープンソースライブラリへの貢献等) を積極的に伝えると良いでしょう。

受託開発とは

受託開発とは、アプリケーション開発をする専門の会社(システムインテグレーター・SIer) が、開発機能を持たない会社からアプリケーション開発を依頼され、その依頼に従ってアプリケーションを作り、納品することをいいます。

開発を依頼する際に、どういったものを作ってほしいかを契約書で取り決め、受託開発会社はその契約を満たすものを作ることを最終ゴールとします。開発物がどれほどのビジネスインパクトを発揮するかは考慮する必要は無く、指示されたものを忠実に作ります。早く納品することが一番の価値となります。

場合によっては、アプリケーションサービス提供会社(発注者)が得た売上成果の一部を開発会社の売上とする「レベニューシェア」という形態を取る場合があります。ゲームなど、開発技術が売上に直結するようなものだったり、継続的な機能追加が必要なものはレベニューシェアとなる場合が多いです。レベニューシェアの場合、開発会社の責任領域がサービス売上にも及ぶため、完全な受託開発より開発の意見・提案が影響力を持つようになります。

現代のアプリケーションソフトウェアは複雑なため、開発依頼時点で開発物の仕様が十分に決まっている場合は多くありません。大抵は、正常に動作するいくつかのパターンの仕様のみが決められており、特殊なケースは考慮されてない場合も多いため、都度依頼者に確認するなどの対応をする必要がります。その際に新たな機能が必要なことが判明し、開発工期の再見積もりが必要になってしまうのはよくある話です。

これは依頼者の考慮不足といえばそうなのですが、現代のアプリケーションを仕様書で完璧に組み上げることは不可能です。完璧を目指せば、それはプログラムコードと同じものになるので、人に依頼するよりコードを書いたほうが早いってなります。

開発依頼時点で開発物の仕様が十分に決まっていない理由としては、「最終目標に破綻の無いように、詳細な動作仕様を決める」というところまで、依頼内容に含むと考えていることも多いです。どこまでを誰が考えるか、あいまいなまま開発を進めてしまうと、問題が発生した時に責任問題となりますので、契約時の段階でアプリケーションサービス提供の内容をお互いにしっかり合意しておく必要があります。…が、現代のプログラムは契約書で責任分掌がはっきりできるほど単純なものではないので、けっこう揉めることは多いです。大きなコミュニケーション能力が必要とされます。

会社によるかもしれませんが、求人応募者に対してそれほど技術的な点を深く求める会社は多くないように思います。開発未経験でも学歴を見て採用が決まる場合は多いと感じます。

受託開発会社は、社員がほぼエンジニアで構成されるため、知識が共有しやすく、能力による給与評価や昇格も制度が固まっていて、フラットに行われやすいように思います。

自社開発・受託開発 どちらが良いか

個人的には、断然自社開発をおすすめします。業務課題を社内のチームで共有し、みんなで解決策を考え、開発したサービスが顧客体験に直接影響し、会社の売上につながっていく様子を間近で見れることは、エンジニアにとって大きなモチベーションとなります。これこそが、開発をしていて楽しいと思う瞬間です。

ただし、会社によっては開発チームの技術が停滞していたり、経営層が開発チームに十分なコストを投資しない場合があり、そのような会社で開発者を続けていくのはかけがえのない人生を棒に振ることになりますので、十分考慮して判断するようにしてください。

アプリケーション(プログラム)開発とは何か

新しい価値の提供

今まで全く存在しなかった価値を、エンジニアは作り出すことができます。ゲームによるエンターテイメント体験、SNSによる承認欲求の充足、動画投稿サイトでの顧客間での放送、動画ミーティング、顧客間での商取引サービス…昨今台頭した強い新体験を持つサービスは、アプリケーションエンジニアリングの賜物です。これらのサービスは、スマートフォンやPCなどあればどこでも利用できるため、使用者は金銭的にも時間的にも、心理的にも安価に体験を得ることができます。スマートフォン含め、最近の情報機器もサービスも、どこかの会社のエンジニアとボランティアのエンジニアの協力により成り立っています。

雇用コストの削減

例えばECサイトで商品を販売することで利益を上げている会社の場合、接客・商品の販売・代金の回収 すべをプログラムで処理します。おそらく、商品の在庫管理、発注、会計処理などもプログラムが行っています。このプログラムは、会社の業務フローそのものです。エンジニアは、この「会社の業務フローそのもの」をメンテナンスする仕事です。

現代の業務フローは、大量のデータをルールに沿って自動的に処理するために、プログラムによる自動化が必須です。自動処理を構築しない場合、その分余計な人件費がかかることになります。

雇用の賃金が上がり、労働の自由度が増すことで労働者が働きやすくなるほど、経営者は人を雇いにくくなります。また、情報処理はより複雑化しながらも、PCは高性能化し利便性が高くなったことで、知識が乏しい人が誤った情報の使い方をした場合、指先ひとつで会社を終わらせるような情報漏洩被害に発展する場合も考えられます。日々、それを誘発するような攻撃を仕掛け続けている人もたくさんいます。現代において、人を雇用するというのは大きなコストとリスクを負うことになります。

会社にとって、同じ経常利益を上げるとしたら、人は少ないほうが絶対に有利です。人が行う処理をプログラムにすることで、雇用という大きなコストとリスクを回避できます。
プログラム開発者は、人が行っている業務フローを自動化し、人がいなくても(採用しなくても)機械を使うことで自動的に大量の情報処理ができる組織を構築することができます。
究極的には、人的労働力をほぼかけずに商品を販売し続けるサービスを、全業種の中で唯一エンジニアは作ることができます。

コンビニは、店舗のマネージャーが業務フローマニュアルを使ってアルバイトの店員をマネジメントすることで商品を販売します。ECサイトの開発者は、人を使わず機械をマネジメントすることで、商品を販売します。そのマネジメントするための業務フローを記述したものが、プログラムというわけです。

今後の雇用情勢

エンジニアは、雇用する人数を減らすことのできる唯一の職種といえます。現在、色々な会社で業務フローは高度にプログラムにより自動化されていってます。エンジニアは業務フローを自動化でき、雇用を削減できる職種として、会社経営者から強く求められており、人類の理想とするAIが誕生するまでこの情勢は変わらないと考えます。プログラム開発を仕事にして、前線を走り続けることで、仕事に困ることは無いでしょう。

開発者の担当領域による分類

ゲーム開発者

現代では、Unity や Unreal Engine 等ゲームエンジンを使ってゲームを開発する人です。
私は専門外なので割愛します。

組み込み/IoT エンジニア

家電や自動車制御プロセッサ、自動販売機、デジタル看板、ルーターやLANハブなどのプログラムを開発する人です。
基本は C++ や Java だと思いますが、最近は開発環境の進歩により、 C#, JavaScript, Python などでも開発できます。
私は専門外なので割愛します。

Webアプリケーションエンジニア

ネットワークを介して処理をするアプリケーションを作るエンジニアです。
基本的にはブラウザ上で動くアプリケーションを作ります。

現代は様々なものがネットワークにつながるようになっており、家電もネットにつながったりしますし、スマホにインストールするモバイルアプリも大抵はネットワークを介してサーバと通信することで機能を提供します。そのサーバサイドを作るエンジニアでもあります。

アプリケーションエンジニアになるには

まず、全くの未経験であれば、教則サイト ( Progate, PyQ 等) の有料会員になって、最後まで進めましょう。最初はモチベーションが上がらずに、苦痛を感じるかもしれませんが、最後まですすめてください。教則サイトは誰にでもわかるように一つ一つ丁寧に教えてくれます。もし、教則サイトで知識的に躓くようであれば、エンジニアに向いてないように思います。幼稚すぎてだるい、と感じるようであればちょうど良いです。

10年前であれば、有名な本を買ってそこから学ぶのが効果的だったと思いますが、今は親切丁寧に解説してくれる教則サイトがいくつもサービスされていますので、便利に使いましょう。

教則サイトを一通り終わらせることができれば、おそらくプログラムとは何なのかが体感できたはずです。次は、自分の生活の中で困ったことを開発で解決させてください。

例えば、PCを使っている時に、自動的にフォルダ内の全ファイルをリネームしたいとか。ネット上に散らばっている画像を自動的に収集したいとか。クリップボードにコピーした文字列を自動的に整形してどこかに共有したいとか。自分の所属するサークルやクラブのための情報共有ツールを作りたいとか、スコアを統計したいとか。まわりを見渡すと、アプリケーションエンジニアリングで解決できそうなことが山ほどあるはずです。

ひとつづつ、手をつけていきましょう。おそらく、なんとなくロジックはわかるけどどういうプラットフォーム上でプログラムを動かしたらいいかわからない、という状態になるのでは無いでしょうか。

テキスト処理や計算処理をするだけなら、HTML + JavaScript だけで解決できる場合もあります。

計算するだけなら、 Google Colaboratory で十分かもしれません。

スプレッドシートやメールを自動処理するなら、Google Apps Script が良いでしょう。

Mac でファイルに対して自動処理を処理したいなら、ターミナルで動くテキストベースのアプリケーションスクリプトを書きましょう。最初は Python か Node.js がおすすめです。

Apple や Google の App Store に並んでいるような綺麗でかっこいいアプリを作る必要はありません。まずは、自分の身の回りのことを、自分でコードを書いて自動化していってください。技術がついていかず、途中で開発が詰まることはよくあると思いますが、考えてもわからないものは一旦放置して、別の問題を解決するコードを書いてください。

できたコードは Github に プライベートリポジトリにして保存しておきましょう。もし、公開してもセキュリティ的に絶対大丈夫だと自信があるものだけ、パブリックリポジトリにして上げてください。

多くのコードを自分で書かなければいけないわけではありません。誰かが作ってくれている、素晴らしく便利なものをうまく組み合わせて、自分の課題を楽に解決してください。会社内のエンジニアの仕事というのは、いつもこの延長です。有料のサービスも、無理のない範囲でどんどん使いましょう。機械的な動きや計測が求められるラズベリーパイやスイッチボットなども買って使ってみましょう。

慣れてきたら、Webサイトを作成しサービスしてください。最初は自分のポートフォリオやブログ だったり、自分の趣味研究の成果の公開、またはサークル・クラブのサイトを作るのが、モチベーションを高く保てて良いと思います。ログイン機能を提供するなど個人情報を扱う場合は十分注意し、絶対に自作はせず、認証サービス ( Firebase, Cognito, Auth0等 )を使うか Webアプリケーションフレームワーク(Django, Rails, Laravel等) を必ず使うようにしてください。

あとは、自分の思想とあっている会社を見つけて採用応募し、「自分が今までどういったことを自動化してきたのか」を丁寧に説明してください。その自動化の成果や方針が会社の思想とマッチしていれば、会社組織の一員として安定したエンジニアリング人生をやっていけます。

フリーランスでやっていくのは、他のエンジニアと良好な人間関係を構築するのにひとつ壁があるため、あまりおすすめしません。ビジネスに共感を持った会社の、正社員として採用されることが、エンジニアとしての人生を豊かにすると、私は考えています。

アプリケーションエンジニアとして生きること

アプリケーションエンジニアは、人間の職業のひとつの極限だと感じています。アスリート、漫画家、数学者、棋士、芸術家などと同様に、「十分な域に達するには一生分の時間では到底足りない」職業です。課題や習得することは無数にあり、一生…60年ほどを使っても、全ノウハウの1%も習得できないでしょう。そのため、自分に合ったスタイルを取捨選択し、日々自分の技術を磨き続ける人生になります。毎日が新しい挑戦の連続で、毎日限界まで頭脳を使い、自分の能力の低さを痛感し、何度も停滞し、何度も失敗します。しかし課題解決をした時のリターンが予想しやすく、かつ経済的な価値が大きいものである場合が多いため、他の業種より安定した生活が継続してできるでしょう。

エンジニアが新しい価値を作り、何かを自動化するということは、おそらくその時点で既存のビジネス(業務) の価値を下げ、いくらかの人への報酬を奪うことになり、エンジニアリングをする人としない人で格差ができます。その社会は20世紀後半から既に始まっています。

もし、あなたがアプリケーションエンジニアになろうと思っているのであれば、先輩として応援します。アプリ開発はめちゃめちゃ面白い上に、人から必要とされます。自分では、今まで開発者をやってきてよかったと思いますし、あなたも10年後、間違いなくそう思います。

特にここ40年は、電子計算が飛躍的に向上し、インターネットが一般化した、人間史の中で一番面白い時期であることは間違いありません。そしてこれからも、量子計算の一般化やシンギュラリティ、人工生命の誕生など従来の人間の価値観が覆るイベントが目白押しです。その転換期に立ち会えることができてよかったと思っています。

Search