お知らせ

Web開発において、よく、サイトを軽くしてほしいという話が出てきます。 HTMLやCSS等のシステムが絡んでいないWebサイトでの重さの原因は９割が画像です。 対応ブラウザを視野に入れながら、webpを入れたり、画像圧縮のツールを使うと良いでしょう。 ただ、システムが絡むものの場合は別です。 この場合、9割がデータベースのSQLの書き方と、テーブル構造です。 データベースとは、データを蓄積しておき、そこに保存し、取得できるソフトウェアです。 端的に言ってしまえば、Webシステムとはこのデータベースに保存したり、取得したりする事がメインとなります。 データベースの重さの原因で最初に目につくのがindexの貼り方でしょう。 indexとはなにか？ 要はデータの目次をつけるものに近いと思って頂ければと思います。 ただ、気をつけるべきは、indexを無闇に貼れば良いとは限らないと所です。 他にも細かいもので、検索順序を変えたり、取得情報を変えたり、キャッシュさせたり、データベースのコンフィグを変更し、チューニングしたり DBサーバーを複数個持ったりと様々な手法があるでしょう。 ただ、何件か重さの改善をしましたが、一番の解消法は正規化を減らすことです。 正規かとはなにか？ 要はデータ情報をグループ化してしまうことです。 果物で言えば、みかんの情報の「カテゴリ」に柑橘系と入れるのは良い構造ではありません。 この場合、他にレモンを作り柑橘系と入れてしまっては、後々情報を変更する際に面倒なことになります。 他に「カテゴリ」の情報を作り、そこに柑橘系を入れておき、「果物情報」と「カテゴリ情報」を紐付けたほうが 後々変更の際に便利なものになります。 なら、何故、その良い技術である正規化を減らすことが良いか？ 少し専門的に言えば、joinやサブクエリを減らせるかです。 もちろん、一番理想的なことは、正規化をしても高速なデータ構造を作るのが理想的です。 ただ、連結するデータがあまりにも増えてしまった場合は(良くないですが。。。)、上記の正規化を止めることも選択肢の一つです。 また、他にも集計を表示時にしているシステムを見かけます。 表示のたびに集計をしていてはシステムも遅くなります。 ここは、登録の際にバックグラウンドで、またはリアルタイム性は損なわれますが 深夜などにまとめて処理をするのも手の一つです。

クライアント様のご要望でFXデモにAdjustを導入しました。 ユーザー様の動向を確認し、ご要望に応えるためになります。 ハイブリッドでの開発のため、導入に少しのコツが必要でした。

最近は、私は制作するのは既存のお客様のみになりつつありますが 新規のクライアント様で開発を依頼されることもたまにあります。 その際に多くあるのが、海外の方に発注して完成しなかったというものです。 もちろん、海外の方の開発スキルも低いものではありません。 ただ、どうしても障壁があるのです。 1.言葉の壁 一番お聞きするのがこれです。 これは避けようのないものです。 「お願いしたものと違うものが出来上がった」 これは言語が通じないので当然のことでしょう。 よく、日本の翻訳の方が間にいるから大丈夫と言われることがありますが これは、正直リスクが高まるだけです。 クライアント様→日本の方→実際作業する外国の方 人が多く入るため、実際作業する方の指示がより曲がって伝わってしまいます。 実際に開発する方が日本語が出来ればまだ良いのですが これでも、日本語を完璧に理解できるわけではないため、意図は曲がってしまいます。 2.考えの違い 海外に発注するにおいて、当初の仕様は絶対です。 これは当然といえば当然なのかもしれませんが、当初の仕様になかったことは 作業してくれないことが多いようです。 私も含め、日本のエンジニアの方はこの辺りは融通を利かせて対応することが多いです。 もちろん、仕様書の作成は前提ですが、書類を作成しても 実際触ってみて「あれ？　違うな」という事は起きえることだと考えています。 この辺りもトラブルの原因になっているようです。 また、海外の方は責任感で動くことは少ないです。 あくまで「お金」で動きます。 報酬が近日払われるものを優先するのです。 また、システム的な物が違ったりします。 それはやっておくべきだろうという箇所が、やっていないことが多いようです。 また、それを対応してくれないことが多いと聞きます。 （例：保存後のアラートメッセージやお問合せなどのフォーム入力時の確認画面） この辺り、理解、納得の上での発注であれば、海外発注も良いとは思うのですが 中々、難しいように思えます。

Windows11が発表されましたね。 Macを使っているため、私には直接的な開発環境の不便は出なそうですが テスト環境としては所持しております。 以前はシステム開発時に、IEの恐怖がつきまとっていましたが、最近ではChromeのエンジンのChromiumをベースにした Edgeが主流になりつつあるので一安心です。 Androidのアプリが動くようですね。 スマホアプリがPCで動作するのはappleが行っているため必要に迫られていたのでしょう。 Windows Phoneが上手く行っていれば問題なかったのでしょうが、シェアを取ることが出来ませんでしたからね。 タスクバーの移動が出来なくなる予定があるため、バーを下以外に移動させている人には痛手でしょう。 また、CPUの制限が厳しいとのことのため、ここもネックでしょうね。 最近は、半導体不足からか、PCやタブレットの供給が追いついていないため 買い換えるのも大変かもしれません。 私の注文した「Fire HD 10 タブレット 10.1インチHDディスプレイ 32GB ブラック」も 8月26日から9月22日の間に到着予定という長期スパンの発送になっています。 WindowsはMacと違い、様々なデバイスを対応しているため、どうしても不具合が増えてしまいます。 懸命にシステムを開発した方々には頭が下がりますが、ネットではあまり歓迎されていないようです。 昔はOSの最新版が出るとそれだけでワクワクしたものですが、アイデアも出尽くしてしまったのか 最近は革新的な機能も出てこないため期待が薄いのかもしれませんね。

この二点を使用することが非常に多いです。 Web開発会社の方々も使われている方が多いのではないでしょうか？ この記事を見るような方には説明不要な内容かもしれません。 Vue.jsは導入するサイトを選ぶため使用しないことも多いですが（SPAのサイトに向いているように思えます） TypeScriptは使用する頻度が多いです。 従来の動的型付け言語のjavascriptを、静的型付け言語として使えるのが主な特徴です。 要は最終的にはjavascriptにビルドして出力してくれます。 静的型付け言語が何なのか。 要するに変数や関数に文字型なのか、数字型なのかを定義することが出来ます。 動的は定義することが出来ずに、どの形式のデータも入ってしまいます。 動的な方が便利ではないか？ 私もそう考えている時期がありました。 何でも入ってしまうということはエラーが抽出できないことになるのです。 本来は数字が入らなければならない動作に、文字を入れてしまうプログラムを組んでしまうこともあります。 しかし、動的型付け言語の場合は実際使用してみるまでわからない可能性が高いです。 最悪リリースしたもので致命的なエラーを起こすこともあります。 しかし、静的型付け言語の場合はビルド時にこのエラーが出てくれるため、上記のエラーの早期発見が期待できます。 また、本来は ・メモリの最適化 ・よってパフォーマンスが上がる 等のメリットもあるのですが、TypeScriptの場合は最終的にはjavascriptが実行されるので、これらの恩恵があるとは思えません。 初期の段階で、javascriptも静的型付け言語だったらありがたかったのですが。。。

先日、リリースしたFXトレーディングカレッジが1.1になりました。 リリース時の該当記事 今回はチュートリアルを入れ、ユーザー様に一層使いやすくなっております。 FXをこれから始める方にお勧めです。

クライアント様のご依頼で、FXトレーディングカレッジのアプリを開発しリリースしました。 FXを勉強されたい方にお勧めです。 ダウンロードは下記からお願いいたします。 https://apps.apple.com/jp/app/fx学習アプリ-チャート分析と実践トレード手法をプロが解説/id1569342318 https://play.google.com/store/apps/details?id=com.trader_college