if for while switch
関数の作成と利用 可変引数 可変引数の逆 参照渡し 参照渡しに関して
変数の型 変数の扱い 変数の扱い2 文字列と結合 文字列と結合2 四則演算と余り 演算子の優先順位1 演算子の優先順位2
四則演算と余りと累乗 比較演算子 文字列演算子 ビット演算子 論理演算子
Eclipseのインストールから基礎文法までの解説Javaの概要
本番環境のOS 本番環境のサービス 開発用テスト環境
フレームワークとは 代表的なフレームワーク このサイトで利用しているフレームワーク MVC
サンプルソースコード https://github.com/mofon001/PHPTest正確な情報は公式のドキュメントを読むのが確実である
公式のコマンドラインツールも存在するが、Windows環境ならA5:SQL Mk-2をおすすめする。A5:SQL Mk-2からSQLiteの操作方法
SQLiteは組み込み型データベースであり、サーバを必要とせずプログラミング言語やOSの標準機能として搭載されていることも多い。 データはその場でファイルとして保存されるが、履歴ファイルを作りつつ安全に更新されるため、そうそうデータが壊れることはない。 処理速度は高速で、処理によっては下手なデータベースサーバより速いこともある。複数のプロセスやスレッドから同時アクセスも可能であり、欠点があるとすれば標準でネットワークアクセスできないことぐらいである。
インストール サンプルアプリケーションの作成 nginxの設定
ここではPHP7.3をnginx経由で使えるようにしますインストール 起動設定 nginx側の設定 動作確認
Windowsのプロンプトで操作していると、色が見えにくかったりカーソルが消えたりするので、sshを使えるようにすることをオススメします。インストール 起動設定等 パスワード認証の許可 公開鍵による認証 接続方法
WSLを有効にする Ubuntuのインストール 起動方法 最初に行うコマンド
インストール 起動設定 設定ファイルの場所 ユーザの作成 外部接続の許可
WSL+Ubuntuではaptで一通りのパッケージをインストールすることが出来ます。もちろんnginxもすんなり入ります。インストールと起動 動作確認 自動起動の設定 手動の起動/停止用BATファイル Windowsの一般領域をコンテンツ置き場にする
WSL(Windows Subsystem for Linux)はWindows10(1709)以降に搭載されたLinux用のSubsytemです。これを利用することによってLinuxのプログラムをWindows上で動作させることが可能です。WSLと仮想環境の違い Ubuntuを入れた場合のネイティブLinuxとの相違点 用途に関して
UbuntuでNode.jsの10系統を使用し、Nginxと連携するところまでを解説するインストール インストール結果の確認 テストアプリケーションの作成 Nginxの設定 結果の確認
Let's Encryptによるhttps環境の構築2(自動設定)
こちらはMyDNSの公式プログラムを利用して、ワイルドカードの証明書を自動取得する方法です最小限の労力でhttps化するのなら、こちらが近道です前提条件として必要なもの MyDNSの公式プログラムのインストール MyDNSのアカウント設定 証明書の発行
PHPを利用するに当たってApacheであればモジュールとして内部に組み込むことができる一方nginxはphp-fpmを別に起動して連携する方式となるphp-fpmのインストール php-fpmの起動と有効化 php-fpmにnginxと連携するための設定を行う nginxからphp-fpmに接続するための設定 確認方法
確認用にコンテンツを2種類用意するVirtualHost用コンテンツを用意する nginxの設定 ブラウザで確認
インストールと起動 設定ファイルなど 動作確認 トップページの内容変更
一昔前はWebサーバと言えばApacheだったが、軽量で高速に動作するサービスが求められnginxが利用されることが増えている ここではnginxの基本的な設定方法を紹介する
Linux上でWebアプリケーションを組む場合、面倒になるのがコンテンツのアップロードだ Sambaを利用することによって、直接ファイルが編集できるようになるので、そのあたりがかなり楽になるファイアウオールに穴を開ける(GCEを使用している場合) パッケージのインストール サービスの起動と有効化 Samba用ユーザの作成 確認 書き込みアクセスの許可
無料で利用できるMyDNSのサービスを利用して、サーバにドメイン名をつける方法を解説するMyDNSの利点は、動的IPでもドメイン名とIPアドレスを関連付けられることだ AdSenseを利用しようと思っている場合、MyDNSの無料ドメインでは審査が通らないので独自ドメインが必要となる独自ドメインを安く取得したい場合は一年目の価格が安いお名前.comをおすすめする取得した独自ドメインをMyDNSに持ち込むことも可能だダイナミックDNSとは ユーザ登録 利用するドメインの設定 通知コマンド 自動通知
Webコンテンツに対するアクセスを行う場合使われるプロトコルはhttpかhttpsである。httpsは暗号化されているため、セキュリティ面で使用が推奨されている。 ただしhttpsを使うためには、認証局(CA)に証明書を登録しなければならない。有料のCAを使うと年間に数万円の費用が発生する。これを無料で行ってくれるのがLet's Encryptである。 Let's Encryptで発行した証明書は、ドメインに関する操作権限は確認するものの、発行先の身元の証明は一切無い。ドメイン所有者との通信を保証することだけが目的となる。必要なものをインストールする VirtualHostのデータを削除 証明書の作成 VirtualHostの設定 証明書の定期更新
rootにパスワードをつける root権限を得る AppArmorの無効化 swap領域の作成 タイムゾーンの設定
前提条件としてGoogleのGCP(GCE)環境下でのUbuntu(対象18.10)のサーバ構築方法をまとめていくちなみにCentOS7とUbuntuを比較すると、ランタイムやアプリのデフォルトのバージョンがUbuntuの方が新しいものを使用しているできるだけ新しいものを利用したいと考えるならUbuntuをおすすめするちなみに真に新しいものに飛びつきたいのならFedoraが一番だが、飛び抜けすぎていてGCPにはパッケージが提供されていないおそらく危ないからサーバで使うなということなのだろう
PHPを利用するに当たってApacheであればモジュールとして内部に組み込むことができる一方nginxはphp-fpmを別に起動して連携する方式となるphp-fpmのインストール(PHP7.3) php-fpmの起動と有効化 php-fpmにnginxと連携するための設定を行う nginxからphp-fpmに接続するための設定 確認
インストールと起動 設定ファイルなど 動作確認 トップページの内容変更
一昔前はWebサーバと言えばApacheだったが、軽量で高速に動作するサービスが求められnginxが利用されることが増えている ここではnginxの基本的な設定方法を紹介する
VirtualHostとはドメイン名によって、コンテンツを切り替える機能である 前項目のMyDNSの設定が終わっていることを前提に設定を行っていくVirtualHost用コンテンツを用意する nginxの設定 ブラウザで確認
モードに関して 必要頻度の高いコマンド バックグラウンドに関して 不正終了
・ファイルの末尾を表示 tail ファイル名・ディレクトリの作成 mkdir ディレクトリ名・ディレクトリの削除 rmdir ディレクトリ名 rm -r ディレクトリ名・ファイル内容の表示 cat ファイル名・ファイル内容を終端部分のみ表示 tail ファイル名・ファイルリストの表示 ls・ファイルリストの詳細表示 ls -l・ファイルリストの隠しファイルの表示 ls -a・カレントディレクトリの表示 pwd・カレントディレクトリの移動 cd ディレクトリ名・テキストファイルの編集(細かい使い方はviエディタの使い方を参照) vi ファイル名・ファイルの削除(削除するかどうか聞いてきた場合はyを入力すること) rm ファイル名・ファイル名の変更/移動 mv 移動元 移動先・ファイルのコピー cp コピー元 コピー先・管理者権限の取得 su -・属性の変更 chmod 属性 ファイル名 属性 a:全て u:所有者 g:グループ o:その他 +:追加 -:削除 r:読み込み w:書き込み x:実行 例 chmod o+w file.txt・所有者の変更 chown ユーザID:グループID ファイル名 -R 下の階層すべて 例 chown -R x13g000:x13g000 ファイル/ディレクトリ名・サービスの起動/停止等 systemctl アクション サービス名 アクション start(開始) stop(停止) reload(更新) restart(再起動) 例 systemctl start network・サービスの自動起動設定 systemctl アクション サービス名 設定 enable/disable 例 systemctl enable network ・パッケージのインストール yum -y install パッケージ名・IPアドレスの表示 ip a・再起動reboot・シャットダウンpoweroffhalt
基本コマンドとviエディタの使い方は覚えておこう
主にGCE環境下での各種サービスの設定方法など
CentOSとUbuntuの違いのメモ
基本文法を学ぶ前に、PHPでどんなことが出来るのかを確認する実行環境を用意しておくことをお勧めする基本動作 フォームの利用
この項目はサーバ上のPHPプログラムをVisualStudioCodeでデバッグする方法に関しての説明である 前提条件としてnginx、php-fpm、php-xdebug、sambaの設定が完了している必要がある また、sshのポートフォワードを利用するため、クライアントとしてRLoginを前提に説明するxdebugを有効にする VisualStudioCodeの設定 RLoginでのポートフォワード設定 デバッグの開始
Linux上でWebアプリケーションを組む場合、面倒になるのがコンテンツのアップロードだ Sambaを利用することによって、直接ファイルが編集できるようになるので、そのあたりがかなり楽になるファイアウオールに穴を開ける(GCEを使用している場合) パッケージのインストール サービスの起動と有効化 Samba用ユーザの作成 Sambaの設定 確認 書き込みアクセスの許可
今回のネタは最速でPHPのテスト環境を作ることである。テスト環境といっても、本番に近い環境であることが望ましいのは当然である。今回はコピペすればあっという間に環境構築が終わるという流れでやっていきたい ローカル環境でテストするとの違い、サーバでテストするのはデプロイが面倒くさいと思う人もいるかもしれない。しかしファイル共有を有効にするので、デプロイなんて作業は存在しないコピペで作るPHPテスト環境 構築する環境 さあ、コピペの始まりだ！ 何が起こったのか？ 穴を開ける 動作確認 まとめ デバッグしてみる
Webコンテンツに対するアクセスを行う場合使われるプロトコルはhttpかhttpsである。httpsは暗号化されているため、セキュリティ面で使用が推奨されている。 ただしhttpsを使うためには、認証局(CA)に証明書を登録しなければならない。有料のCAを使うと年間に数万円の費用が発生する。これを無料で行ってくれるのがLet's Encryptである。 Let's Encryptで発行した証明書は、ドメインに関する操作権限は確認するものの、発行先の身元の証明は一切無い。ドメイン所有者との通信を保証することだけが目的となる。必要なものをインストールする VirtualHostのデータを削除 証明書の作成 VirtualHostの設定 証明書の定期更新 nginxでLets'sEncryptのアクセスだけhttpsにリダイレクトしない設定
[300円/月]Google Compute Engine格安VPSサーバ構築
低価格で高性能サーバ、そんな夢を叶える方法GCEの特殊な料金 プリエンプティブで安くなる金額 「お前はもう死んでいる」サーバのアンデッド化 話題に上らない格安GCE
ここでは使えそうなテクニックを記載していく予定定期スナップショット用スクリプト GCEのブートディクスを縮小する 中華バリア
この項目はサーバ上のPHPプログラムをVisualStudioCodeでデバッグする方法に関しての説明である 前提条件としてnginx、php-fpm、php-xdebug、sambaの設定が完了している必要がある また、sshのポートフォワードを利用するため、クライアントとしてRLoginを前提に説明するxdebugを有効にする VisualStudioCodeの設定 RLoginでのポートフォワード設定 デバッグの開始
無料で利用できるMyDNSのサービスを利用して、サーバにドメイン名をつける方法を解説するMyDNSの利点は、動的IPでもドメイン名とIPアドレスを関連付けられることだ AdSenseを利用しようと思っている場合、MyDNSの無料ドメインでは審査が通らないので独自ドメインが必要となる独自ドメインを安く取得したい場合は一年目の価格が安いお名前.comをおすすめする取得した独自ドメインをMyDNSに持ち込むことも可能だダイナミックDNSとは ユーザ登録 利用するドメインの設定 通知コマンド 自動通知
GCEのコンソールまでたどり着く インスタンスの作成 インスタンス始動！ ssh接続 RLoginの設定 ここまで出来たらsudoだけ覚えて帰って
GCPとGCE GCEのトライアル
Google Compute Engine (GCE) 入門
Googleの提供するVPSの使い方の解説
VPS(Google系)やLinux(CentOSやUbuntu)などのサーバ構築系情報
rootにパスワードをつける root権限を得る SELinuxの無効化 swap領域の作成 入れておいた方がいいもののインストール タイムゾーンの設定
実動作 https://javascript-windowframework.github.io/jwf_sample01/dist/ソースhttps://github.com/JavaScript-WindowFramework/jwf_sample01/Sample001 Sample002 Sample003 Sample004 Sample005
Node.jsが入っていることが前提ですビルドまでの手順 プログラムを書き換えてみる
JWF(JavaScript-Window-Framework)
JavaScript(TypeScript)で仮想ウインドウシステムを実現します単純なフレームウインドウの他にListViewやTreeViewの機能も実装済みですこのサイトもこれで開発していますnpmで公開中ですnpmによるインストール ソースコード
CUIでファイルやディレクトリを扱う上で最低限必要な知識を確認するディレクトリの種類 ディレクトリの確認 ファイルの確認 絶対パスと相対パス 相対指定
動作させるまで
ディレクトリ構成 初期設定ファイル トップページテンプレート バックエンド:テスト用サンプルモジュール フロントエンド:テスト用サンプル
バックエンド系のAMFとフロントエンド系のJWFを作っています。その二つで作ったのがこのサイトです。
このサイトに関して このサイトが収集する個人データに関して アフィリエイトの関して
システム構成 SPA(Single Page Application) お問い合わせフォーム
前置きがいらない人は、このページは読み飛ばしてください。 TypeScriptによるフロントエンド開発は、素のJavaScript開発に比べ、その開発効率を飛躍的に上げることが可能です。・型チェックによる不正な代入の防止・開発環境と連携した入力補完によるメソッドやプロパティ、パラメータの明確化・最新の文法の対応と古い規格へのトランスコンパイル機能 一般的にTypeScriptはJavaScriptに型が加わった言語だという認識をされることが多いですが、実はそれだけに止まりません。型の定義を専用の定義ファイルに吐き出しておくことで、それを配ればオリジナルのファンクションやインタフェイスの名前やパラメータをチェックすることが出来ます。 例えばフロントエンド開発ではイベントの種類が多すぎて、全パラメータを覚えている人はいないであろうと思われるaddEventListener、これも型定義が用意されています。イベントの名前が網羅され、コールバック用の引数の内容まで開発時に表示されます。間違った使い方をすれば当然のごとくきっちりエラーが出ます。 document.createElementも、そに書いたDOMの種類が型として認識されます。//elementが自動的にHTMLDivElementとなるconst element = document.createElement('div'); これによって、作成したDOMのインスタンスに対して、不正な入出力が出来なくなります。もし追加プロパティなどのカスタマイズが必要な場合は、きっちり書かなければいけないところが逆に面倒ですが、それ以上にメリットが大きいのです。//divにcustomParamという追加プロパティを設定 const element = document.createElement('div') as HTMLDivElement&{customParam?:string}; そしてJavaScript自体もどんどん新しい文法が作られ、どんどん便利な文法が実装されていくのですが、古いブラウザでは対応できないという問題が発生します。特にループやイテレータ系など、使えばコードが簡潔に書けるようなものに関しては、本来ならどんどん使っていきたいところです。しかしそれをやった時点で、ある程度のクライアント環境を切り捨てなければなりません。 TypeScriptなら最新
Node.jsとTypeScriptによるプログラミング入門
Node.jsはサーバサイドのプログラミングをJavaScriptで行うためのフレームワークです。このフレームワークの特徴はランタイムライブラリが非同期を前提に作られていることです。そのため、直列に逐次実行していくプログラミング言語にをやってきたプログラマにとって、慣れるまでは不便や回りくどさを感じることになります。逆にプログラミングを全くやったことのない人間がNode.jsに手を出すのは無謀としか言い様がないので、他の言語を選択することをおすすめします。 Node.jsの特徴である非同期のメリットは、周辺へのデータアクセスが効率的になること、デメリットはプログラムが複雑化しやすいことです。複雑といっても大規模な範囲が複雑化するわけでは無く、個々の部分の記述量が増えるというだけなので、それほど致命的な問題にはなり得ません。 また、Node.jsはシングルスレッドを前提としており、マルチCPU環境での性能を出せないと言われることが多いですが、これはプロセスを複数立ち上げれば解決します。他のスクリプト言語でマルチスレッドに対応しているものもありますが、結局のところインタプリタ上でリソース共有のためのロックがかかってしまい、性能が発揮できない結果になります。ということでスクリプト言語系は、マルチCPUはマルチプロセスを使うことになります。 性能的を重視するのであればスクリプト言語はやめて、C/C++、golang、Java辺りを使いましょう。TypeScriptに関して
Webサービスを開発する上での、ユーザの体験を阻害するボトルネックについて考えていきたい1．DBに起因するボトルネック 2．アプリケーションサーバによるボトルネック 3．フロントエンドのボトルネック 4．ネットワーク距離の積み重ねによるボトルネック
ここでは技術系のネタで色々思ったことを書いていく
パッケージの準備 ディレクトリとファイルの準備 tsconfig.jsonによるコンパイラの設定 コンパイル 確認
Node.js+TypeScriptによって、SPA(SniglePageApplication)のWebシステムを開発するためのフレームワークです。 最大の特徴は、最小限の追加コードでフロントエンドとバックエンドのデータのやりとりが行えることです。 npmで公開中です。デフォルトで添付しているサンプル
3．バックエンドのTypeScriptをコンパイル済みにすべきかどうか
Node.jsはts-nodeコマンドでTypeScriptを直接実行可能だ。実際は内部でコンパイルしているわけだが、手順的には手動コンパイルの手間は省くことが出来る。しかし私の作っているモジュールを実行時に動的に読み込む方式を使った場合、部分的にエラーが出て動作に支障が生じた。けっこう前のことなので具体的な内容は忘れてしまったが、試行錯誤をした結果、回避は不可能だった。結局、TypeScriptのコードをJavaScriptにコンパイル済みの状態にして運用している。 コンパイル済みにするのは手間がかかるが、文法エラーのチェックが確実に出来るし、起動時にかかるもっさり感も無くなる。余計なトラブルを抱え込みたくなければ、コンパイルして運用する方が無難だろう。
バックエンドの開発のみなら必要ないのだが、フロントエンドで色々と開発していこうとすると、結局必要になるのがモジュールバンドラだ。種類は色々あるが、プラグインの豊富さを考えると最終的にWebPackしか選択肢が無い。npmで持ってきたモジュール類を組み込むのにも必要だし、使いたいcssをTypeScriptのプログラムから直接importするのにも使っている。 WebPackでやっていることをざっと挙げてみると以下のようになる- node_modulesの中のモジュールを結合- TypeScriptのプログラムから画像をimportして、プログラム中で直接放り込む- TypeScriptからscssのインポートとcssへの変換- cssに含まれている画像データを埋め込み変換- TypeScriptで作ったフロントエンドフレームワークの.d.tsの結合(メインとは別のモジュールで使用)- デバッグ用の.mapをかき集めて結合- 出力する.jsファイルの圧縮、最適化- 必要なpolyfillの結合- .auto.tsの拡張子を持つファイルを自動的にビルドに加える- コンパイル状態のキャッシュとリビルドの高速化 素のJavaScriptのプログラムならさらにbabelによって、古いブラウザへのトランスコンパイルなどを挟むところだ。しかしTypeScriptはその機能を兼ねているので必要が無い。追加インストールしたモジュールによっては、必要になることもありえるので、そこは注意した方が良いだろう。ちなみにbabelよりもTypeScriptのトランスコンパイルの方が性能が高く、出力コード量を小さく出来るので、不必要にbabelを使わない方が良い。 また、polyfillが必要な場合はWebPackのentryに加えるか、起点になっているファイルに以下のような記述を加えて、最低限のものだけを呼び出すようにする。これも無理にbabelを挟み込む必要は無いのだ。import 'core-js/features/object'; import 'core-js/features/promise'; polyfillは全部入りの@babel/polyfillを叩き込むのが一番楽なのだが、それなりにデカいのでオススメできない。使用しているものを自動検出する機能も使ってみたのだが、逆にコード量が増えるという悲劇に見舞われたので、自分で
ツリー型情報掲載システム(Node.js+TypeScript版) ソースコード
1．はじめに 2．フロントエンド開発では結局必要になるWebPack 3．バックエンドのTypeScriptをコンパイル済みにすべきかどうか 4．フレームワークのパッケージ化
今回の開発で必要となった知識をざっと挙げてみたいと思う。・HTML/CSS・JavaScriptの文法と特性・ブラウザでJavaScriptを動かすためのDOMを操作や、イベント・Ajaxや人を殺さない方のJSON・TypeScriptの文法と特性・Node.jsの基本的な使い方とランタイムライブラリ・WebPackなどの開発ツールやプラグイン、必要なpolyfill・npmで呼び出す、大海の中に投げ出された中から掴み取るモジュール・DBとSQLとそれを操作するモジュール なんだかんだでWebPackが鬼門だ。情報はたくさんあるのだが、内容が新旧入り交じり、プラグインも混沌としている。自分が必要としているものがなんなのか、最適解を見つけるまで試行錯誤することになるだろう。この辺りの話もこの後の記事でしていきたい。
次回はバックエンドとフロントエンドで導入した開発手法の話になる予定
・軽量の処理ならNode.js・Webサービスを作る上で重い処理ほどPHPの方が速くなるし、さらに重い処理はネイティブ言語系に投げた方が良い・大量アクセス時の省メモリの動作はNode.jsが有利・ 金をかけても問題なく、GB単位でメモリが用意できる環境なら、省メモリがあまりアドバンテージにならない・本気の同時一万アクセスとかは、普通に組んでたら無理なので夢は見ないこと
Node.jsに向いている作業は最初に書いた通り、受付オペレータである。Webシステムならば、クライアントからの要求を聞き、それをDBに投げ、結果が返って来たらクライアントにデータを送り返すのだ。できるだけ内容に関知しないことが理想だ。しかしこれだけは最低限処理しないといけないというのがある。クライアントが誰なのか、問い合わせが正当なものなのかの確認だ。つまり向いている作業とは、WebAPIを構築する部分である。 ではHTMLは誰が作るのという疑問を抱くかもしれない。初期ページ以外はフロントエンド側で動的に生成すれば良いのだ。バックエンド側は生成に必要なデータを返してやるだけで良い。場合によってはサーバサイドレンダリングが必要なこともあるかもしれない。しかしそれを主体とするシステムに導入するのは考え直した方が良いだろう。
Node.jsの特徴は、細かい処理を大量に捌くことだ。たとえば受付のオペレータのように、用件を聞いたら対象の部署へ内線を回すという作業などが該当する。間違っても重い荷物を持たせてはいけない。Node.jsは荷物を持った瞬間に腰痛を発症し、手痛い損害賠償を請求されることになるだろう。 重い処理とはなんなのか。画像加工とか機械学習とか動画編集とかはもちろんこれに該当する。そういうWebサービスを作るなら、別の言語で作ったプロセスにいったん投げた方が幸せになれる。 そしてもっと一般的に行われている中でやってはいけない仕事、それはDOMを組み合わせてHTMLデータを作成する作業だ。ぶっちゃけこれをやらせるなら、PHPとかに処理を任せた方がよい。その方がよっぽど高速だ。 HTMLデータを生成する作業を主体とするのなら、はっきりいってNode.jsという選択は愚策といってよい。踵を返して他の言語の門を叩いて欲しい。Node.jsで開発しても、面倒なだけでちっとも作業は効率化しない。
Node.jsはシングルスレッドかつ非同期を前提に動作する。非同期は必要なデータが返ってくるまでラグのある処理をタスクプールに積んでいく。ファイルの入出力からDBアクセスまで、その場で欲しいデータをことごとくその場でもらうことが出来ない。データ受け取り後に必要となる処理を切り分けて、ひたすらプールにため込んでいくのだ。これが非同期地獄というやつだ。ただしこの非同期地獄はPromise/async/awaitによって、一応は抜け出すことが出来る。ただし非同期処理にPromiseを返してこないライブラリを扱う場合は、そのまま使うかPromise化するかという面倒な作業が待っている。 この非同期処理に慣れることや、自分が必要とするライブラリのPromise化が終わったら、ようやく開発の門の前に立った状態となる。そう、門前に立っただけである。つまり、まだ入門すらしていないのだ。 ちなみにシングルスレッドだと、複数CPUがあっても、そのリソースを活用できないという認識はしなくて大丈夫だ。プロセスを増やせばリソースは使い切れるし、それを簡単に行う仕組みも用意されている。どのみちスクリプト系の言語はマルチスレッド対応言語でも、変数などの排他制御の問題で性能が頭打ちになる。そうなると結局マルチプロセスしか選択肢が残らない。マルチスレッドで性能を追求したければ、ネイティブ系の言語か、Javaを使った方が幸せになれるだろう。- 非同期処理は、使用するライブラリを全てPromise化してからが始まり- とにかく慣れるまでが辛い- シングルスレッドでもマルチプロセスにすればCPU資源を生かすことは出来る- 非同期処理の同期をとらずに気軽に大量のループで回すと不幸が訪れる- ガチで性能を追求するなら別の言語へまとめ
・JavaScriptから移行するのは、それなりの覚悟が必要・TypeScriptの型の仕様を本気で突き詰めると、実はシャレにならないほど複雑・TypeScriptの言語仕様はこうしている間にも増え続け、気がつくと背後に知らないキーワードが立っている・anyを自分のソースコードから完全に除去しないかぎり、素のJavaScriptの呪縛からは抜け出せない・エラー流星拳に対して、身を守るためにクロスを纏うことは出来ないが苦労はするだろう というかクロスって肝心な場所を守ってない気がする
非同期処理による問題も解決し、いよいよ入門を果たしても、所詮は門を通り抜けたに過ぎない。そこからTypeScriptという地獄が始まる。フロントエンドとバッグエンドを同じ言語で書けるという利点を生かすため、以前に別言語で作った資産を移植する作業をしなければならない。つまり、以前作った資産が多い人間ほど、重い荷物を背負うのだ。 私の場合、ブラウザ上でウインドウシステムを実現するというフロントエンドフレームワークという資産があった。これを移植しなければならないのだ。荷物があまりに重すぎたので、単純移植を諦め、ほとんどの部分を作り直した。 フロントエンドで書いていたJavaScriptのTypeScriptへの移植は、同じ系統の言語だからすぐに出来るだろうとか安易に考えてはいけない。コンパイルした瞬間、流星のごときエラーメッセージによって、自分の甘さをとことん教えられるのだ。ここで必要なのは、エラーの数に心を折られない精神力だ。 こんなに型でカタカタしなくてもいいだろうにと思って、一つ一つ修正していくと、実は馬鹿をやっていた記述をいくつも発見することになる。そう、ここでたまたま動いていたコードを見つけることになるのだ。さらに段階的にstrictを有効にして、チェックを厳しくしていく必要がある。最終的にeslintを導入してanyすら禁止すれば、ようやく入門を完了した状態となる。anyが一個でも残っていたら、入門から脱したとは言えない。 PHPからTypeScriptの移植は文法が似ているおかげもあって、非同期への対処が終わっていれば、意外にあっさり出来る。JavaScriptで食らったペガ○ス流星拳に比べれば衝撃の度合いは低い。まとめ
3．異世界転移のJavaScriptと自らを縛るTypeScript
JavaScriptはクセの強い言語だ。書きたい処理を書くのは簡単なのだが、実は仕様が複雑で、なんだかよく分からないけれど動いているから大丈夫なのだろうというプログラムを書いてしまいがちである。コールバックされたときに今持っているthisが何のインスタンスを示すのか、外側のブロックから拾ってきた変数のデータがいつのものなのか、気を抜いてうっかりしていると命を取られかねない。 受け取った変数のパラメータの取り方は本当に正しいのか、オブジェクトの中身がどうなっているのか、うろ覚えのプロパティ名前が本当に合っているのか、実は一瞬たりとも気を休められない。しかし本当に恐ろしいのは、実は間違っているのに何事も無かったかのように動くことにある。好き勝手に色々書いていたら、いつの間にかそこが異世界と化しているのだ。 この危険を回避するにはJavaScript単体の使用をやめ、TypeScriptで自らを拘束する以外に方法が無い。自らの意思で手かせを付け、足に鉄球と鎖を巻き付けるのだ。身動きがとれない苦しみと引き換えに、突然の異世界転移は防ぐことが出来る。異世界で無双するのは「なろう」だけで十分である。
1．はじめに 2．Node.jsによる完全包囲 3．異世界転移のJavaScriptと自らを縛るTypeScript 4．PHPからNode.jsへの移植作業とその理由 5．Node.jsの特徴 6．非同期地獄と入門と門前 7．TypeScriptと流星 8．必要となる知識 9．次回の予定
https://a5m2.mmatsubara.com/一通りのメジャーなデータベースに対応するクライアントソフトこのソフトのいいところは接続にネイティブ対応しているので、余計なライブラリをインストールする必要が無いことだ
VisualStudioCode SourceTree Snipping tool draw.io RLogin A5:SQL Mk-2
ツリー型情報掲載システム(Node.js+TypeScript版) このサイト ソースコード Node.jsとTypeScriptでこのサイトを作ったので、開発に関連する話をしていきます。今回は導入部分です。変な文章を書いた方が読んでもらえるみたいなので、この後は書き方を変えます。
Windowsに標準でついている画面のキャプチャツール選択した場所を直でクリップボードに保存してくれる機能のおかげで、このサイトの編集が非常に楽であるWindows10には画面スケッチという機能もあるが、あちらはキャプチャ画像を勝手に縮小するため使い物にならない
Node.jsとTypeScriptによる高速かつ軽量なWebシステム構築
ここのシステムの制作話をまとめて行く予定です。
https://ja.atlassian.com/software/sourcetree gitをGUI環境で使うなら、入れておいた方が良いアプリ 所々クセがあるが、バージョン管理が楽になる
https://code.visualstudio.com/ 出だしはVisualStudioからテキストエディタを切り離して軽量化したといううたい文句だったが、どんどん機能が追加され凄まじいことになってしまった Web系の開発を行うなら、すでに本家を超えている
遅延も積もれば山となる。 そもそもネットワークの距離とは何か。一般的にはルータを跨ぐことによる遅延や、物理的な距離による電気信号到達までの遅延を総合したものだ。 前者のルータを跨ぐ数、ホップ数と呼称されるものだが、この数が多いほど遅延が発生しやすくなる。インターネットの過渡期、ルータ機器の性能が低かったころは、この数による影響はかなり大きかった。しかし最近は相互接続網の強化やルーティングプロトコルの改善、機器の処理速度の向上によって、それほど神経質になる必要は無くなった。 後者の物理的な遅延はどうにもならない。電気信号は光の速さで送受信することが出来るが、つまり一秒間で地球を7.5周しか出来ない。日本国内への送受信よりも、日本とアメリカ間のやりとりの方が時間がかかるのは自明の理である。人類が光の速度を超える通信手段を持たない以上、物理法則を超えることは出来ないのだ。対処法はユーザの近くにサーバを配置することである。ワールドワイドなサービスならば、各国のリージョンにサーバを置いていけば良い。ただしやっぱりデータの同期問題が発生するので、国ごとにどういうデータの扱いをするのか、きちんと設計しておく必要がある。 さて、Webシステムを組むに当たって何を考慮しなければならないのかを説明しよう。当然物理法則は超えられないが、気をつけるべき点を気をつければ、遅延は最小限に抑えられる。 データのやりとりは、極力ゼロ距離に抑えることを前提とし、アプリケーションサーバとDBサーバを一つのサーバインスタンス上に配置する。実はこれが結構重要なのだ。アプリケーションサーバが発行するQueryを同期的に行った場合、ネットワーク距離に応じた遅延がその度に発生する。この距離を無くし、プロセス間通信を前提にすれば、その遅延を限りなくゼロに近づけることが出来るのだ。プロセス間通信においてはTCPの使用をせず、UNIXドメインソケットを使うのも重要である。 どうしてもアプリケーションサーバとDBサーバを同じサーバインスタンスに配置できないのであれば、そのやりとりを非同期化することを考えるべきだろう。できる限り並列にQuery投げる構造であれば、遅延の影響は受けにくい。マルチスレッドやNode.jsの非同期処理が有効な手立てだ。 Webサーバとアプリケーションサーバの通信は、ネットワーク距離の部分ではそれほどシビアでは無い。元々が並列アクセスで処理
ブラウザの表示部分による問題だ。最も起こりやすいのは複雑なDOMによって、最終結果の計算が決定されないことだ。 ブラウザはできるだけユーザに対して素早く表示結果を見せようと頑張るわけだが、無いデータは表示できない。画像のサイズやブロックの幅や折り返し位置など、データの読み込みが進むに従って少しずつ判明するような構造になっていると何度も再計算が発生し、ページ表示が荒ぶることになる。 このあたりの対処法に関しては、比較的ネット上に情報が多い。・CSSやJavaScriptのファイルを一つのファイルにまとめる(HTTP2+SSL環境だと自動的に一つのコネクションで転送されるのであまり効果は無い)・CSSやJavaScriptのファイルを最適化して文字数を減らす(そもそも普通はzip圧縮をかけて転送するので効果は薄いし、文字数を減らしたところでブラウザの解析時間の差は測定不可能なレベルだがやらないよりはマシ)・テーブルタグでレイアウトを作らない(サイズを明確に指定すれば問題を回避することは可能だが、使わない方が良いのは確か)・floatのかわりにflexを使う(計算量が減るのでflex推奨)・画像最適化による圧縮(小さい方が良いのは確か) その他、JavaScriptに起因する問題もある。そもそもJavaScriptの規模が大きすぎて、その実行完了までの待ち時間が大きい場合だ。大手でもGoogleやMicrosoftのサービスでは、それが顕著に表れている。ぶっちゃけ、書かれているコードが悪いとしか言い様がない。 JavaScriptの場合、Ajaxの応答によるボトルネックも発生しやすい。一つデータのやりとりを解決しては、次のやりとりに移行するような組み方をしている場合だ。Ajax自体は非同期なのに、それを完全に殺す組み方だ。対処法はAjaxで送受信すべき命令を複数パックしてイチイチやりとりを発生させず、同時処理するような構造を作ることだ。もちろんアプリケーションサーバ側にも、それに対応した仕組みを用意する必要がある。
アプリケーションサーバはPHP、Ruby、Go、Python、Node.jsなどの言語で書いたプログラムの部分だ。大量アクセスによってCPUが100%に張り付くか、メモリが足りなくなってスワップが発生することによって終焉を迎える。 まずメモリが足りなくなる症状だが、サーバに割り当てているメモリと同時起動を許可しているプロセス数が釣り合っていないときに起こりやすい。CPUが上限に達していないのにメモリが限界を超えているのなら、プロセス数を制限するかサーバのメモリを増やす必要がある。ちなみにメモリの限界を超えたことによって発生するスワップは、もはやまともに動作する望みは無い。そこへ到達した時点で実質試合終了である。そうなる前に対処しなければならない。 CPUが100%に張り付いてしまった場合、根本的にプログラムの中に無駄なコードが入っていないかよく確認するべきだ。Webアプリケーションのボトルネックは、ほとんどがDBの負荷によるものなのだ。もしアプリケーションサーバがCPUを食い潰しているのなら、なにか別の問題を抱えていることが多い。それを見直した上でどうにもならないのなら、サーバCPUの増強やクラスタリングで対処することになる。DBに比べると、アプリケーションサーバのクラスタリングの難易度はだいぶマシである。 ちなみに大量の計算を必要とするような特殊なサービスを提供する場合は、その部分のみを分離してオートスケール化したインスタンスに投げることを考えた方が良い。逆にそれ以外もののをオートスケール化しても、面倒くさいだけであまり良いことはない。
Webサービスを開発する上での、ユーザの体験を阻害するボトルネックについて考えていきたい1．DBに起因するボトルネック 2．アプリケーションサーバによるボトルネック 3．フロントエンドのボトルネック 4．ネットワーク距離の積み重ねによるボトルネック
Webサービスを開発するに当たって、最もボトルネックになる可能性が高いのはDBの部分である。ユーザの数に比例してDBの負荷はどんどん上昇する。ユーザ数が少ないうちは大丈夫だと思っていても、同時アクセスが100を超えたあたりから突然症状が顕著化することが多い。その境目はCPU使用率が100%に到達するかどうかだ。そこに張り付いた時点で、そのWebサービスは終焉を迎える。負荷が負荷を呼び、もう戻ってこない。下手をするとユーザも戻って来ない。 対処法は以下の通りだ・DBに対して発しているQueryを見直し最適化する・Indexを付けるべき場所を間違えていないか確認する・そもそも本当にそのQueryが必要なのか考える・アプリケーションサーバ側でデータをキャッシュする・サーバのCPUやMemoryの増強・レプリケーションとクラスタリング Queryの見直しは基本中の基本だ。場合によってはとんでもない効果を発揮する場合がある。何度も利用される上に変更が少ないデータをキャッシュするのも効果的だ。しかもDBに確認をとる必要の無いデータなら、DB側の負荷を0に抑えることが出来る。 そのあたりの対処をとり、これ以上絞り上げてももやはこの雑巾からは一滴の水も出ない状態になったら、もやはサーバのスペックを上げるしかない。単純にCPUのコア数を増やせば、それだけ終焉を先送りすることが出来るのだ。 もちろんコストが跳ね上がるので、ユーザ数の増加が収益に見合わないのなら、残念ながらそのサービスは打ち止めにした方が良いという判断となる。逆にコストがペイするなら、次はDBを複数に分散させ運用することを考えることになる。ところが分散と口で言うのは容易いが、DBの読み書きで異なるサーバを利用したり、分散したサーバの同期の問題が付きまとう。システム開発当初からそのあたりを織り込んでおけば良いのだが、後からの突然の変更はかなり危ない橋を渡ることになるだろう。 読み込みに関する部分がボトルネックというのなら、前述の通り単純なレプリケーションでDBサーバを増やしていけば良い。しかし書き込みに関する部分が問題であり、そしてもはや小細工が通用しないほどユーザが増加した場合、根本的な設計を見直す必要が出てくる。最たるところではリアルタイム同期を諦めることである。クリティカルな部分と遅延が許される部分を切り分けて、データの分散と統合をおこなうのだ。ただし、このレベ
仕様を決めても、ちょっとしたタイミングでズルをしたくなるときはある。納期が迫っていたり、片づけなければならない仕事が山積みであったりと、精神的に余裕が無いときほどショートカットしたくなるのは人間なのだから仕方が無い。 そこで独立性を無視して最短距離でコードを書く。結果、手続きがグダグダになり、もはや守るべきものが守られない状況が常態化する。この悪い流れは至る所で発生する。 結果として、意思の力を信用せず言語仕様でショートカットを禁じよう、そう考えたのが属性やカプセル化だ。だがそんなものは無意味である。開発者が単独のコードしか変更権限がなく絶対に手出しできないならともかく、複数にまたがって改変可能であれば、ある日ショートカットは仕込まれてしまうのだ。言語の保護機能など賽銭箱に5円玉を放り込んだ程度の結果しか生まない。ただの願掛けでしか無いのだ。 オブジェクト指向とは意思の力で成さなければ成せないのである。
オブジェクト指向で最も重要キーワードは再利用である。そして次に重要なのは独立性だ。オブジェクト指向の前提として、名前の通り各機能(パーツ)をオブジェクトという単位に分解していく。何のためにパーツを作るかと言えば、パーツが一つの機能として独立していれば、他の場所へ持って行っても再利用が効くようになるのだ。 では、特定のシステム専用のコードを書く場合はオブジェクト指向はいらないのかという疑問を抱くかもしれない。答えは否だ。システムを拡張する場合、パーツのメンテナンスが必要となる。何らかの機能を追加する場合、コードを変更するのは最小限の場所へ限定するのが理想だ。各機能が独立して作られていれば、そういった場合の対処を最小限にすることが出来る。 プログラムにおいて最もわかりやすい例はアプリケーションのプラグインだ。プラグインはアプリケーション本体のコードに手を入れず、様々な機能を拡張することが出来る。これが理想的なオブジェクト指向と言える。 ではプラグインのようなコードをシステムに導入させるためにはどうしたらいいのだろう？重要なのは機能に対するインタフェイスを明確に定義することだ。 グラフィックソフトのプラグインを例に挙げて考えてみる。ファイルの入出力、画像に対するフィルタ、UIの拡張という感じで、あらかじめ本体側が機能拡張する余地を作っておく必要がある。本体側には必要なデータにアクセスするためのインタフェイス、プラグイン側には本体から送られてくる命令を受け取るためのインタフェイスを実装する。 重要なのは、このやりとりをするための仕様が明確に決まっていることだ。
ここでは技術系のネタで色々思ったことを書いていく
function getId(name){ //プロパティサービスの取得 var p = PropertiesService.getScriptProperties(); var id = p.getProperty(name); //プロパティの読み出し if(id == null) id = 1; //プロパティが無ければ初期値1 else id = parseInt(id); //プロパティ(文字列)を整数に変換 p.setProperty(name, id+1); //+1した値を設定 return id; //IDを戻す }
function test(){ delMessage(5); }
シート名を入れてくださいvar SHEET_NAME = "";
function doGet(e) { //ロックサービスの取得 var lock = LockService.getPublicLock(); //lock.waitLock(30000); //最大30秒間ロック //シートを開く var sheet = openSheetFile("/SheetTest/SyncTest").getActiveSheet(); var lastRow = sheet.getLastRow()+1; //最終行+1の取得 var id = getId("TEST_ID"); //連番IDの取得 var date = new Date(); //日付の取得 var msg = "ああああ" Utilities.sleep(Math.random()*3000); //順番が崩れるようにウエイトを行う //シートに一行書き込み(文字列を書き込む場合は'を付ける) sheet.getRange(lastRow,1,1,3).setValues([[id,date,"'"+msg]]); //lock.releaseLock(); //ロックの解除 return ContentService.createTextOutput(id); } function getId(name){ //プロパティサービスの取得 var p = PropertiesService.getScriptProperties(); var id = p.getProperty(name); //プロパティの読み出し if(id == null) id = 1; //プロパティが無ければ初期値1 else id = parseInt(id); //プロパティ(文字列)を整数に変換 p.setProperty(name, id+1); //+1した値を設定 return id;
プロパティの入出力 排他制御とID生成
「ブログリーダー」を活用して、空雲さんをフォローしませんか？
指定した記事をブログ村の中で非表示にしたり、削除したりできます。非表示の場合は、再度表示に戻せます。
画像が取得されていないときは、ブログ側にOGP(メタタグ)の設置が必要になる場合があります。
