お知らせ

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

FXのデモでトレーニングできるアプリをクライアント様にご要望をいただき 公開しました。

クラウドワークのマッチングサイトでは「ランサーズ」、「クラウドワークス」が有名ですが よく、開発の失敗事例を聞きます。 紹介などで私に依頼が来る方でもここで失敗した方が多いようです。 誤解がないように、予め書かせていただきますが、これらのサービスはとても素晴らしいものです。 これらのマッチングサイトには大きな矛盾点があるのです。 自営の駆け出しの頃や、たまに、これらのサービスを使う人達は関係がないのですが 矛盾を生んでいるのが頻繁に応募する方たちです。 通常であれば、数件案件をもらえれば、お客様が定着するか、サービスがヒットし それらの方々の対応で新規受注を受けることは必要がなくなるはずなのです。 要するにそのプロジェクトが頓挫してしまったか、システム面などでサービス展開がうまくいかなかった方々が 頻繁に応募するわけですね。 実績が多い人＝素晴らしい人材 という構図では無いということです。 実績が多い人＝何かしらの問題があり、顧客が定着しない人 になるのです。 マッチングシステムを介して再発注されているのではないか？と疑問が出ると思いますが そのメリットは双方に無いため考えづらいです。 クラウドワーク系のマッチングシステムのメリットは システム運営会社がお金を預かるため、受注、発注の両方の方がお金が保証されることです。 お互いが信頼関係が築けていれば、必要がないものになり、かつ、システム手数料というデメリットのみが発生します。 何よりも、一度、システム開発者に依頼した発注の方でも、別の案件をまた募集をかけていたりするように思えます。 前回の依頼した方に依頼すればよいため、ここにも疑問が残ります。 万が一、発注で使う場合は、応募ではなく、直接メッセージを送ることをオススメいたします。

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

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

開発において、恐ろしいことは何か、それは知らないことへの挑戦です。 開発をしていると、未知の技術に出会うときがあります。 制作者でも、開発に関わる全ての事を知っている存在しないでしょう。 クライアントの方のシステムにとって、その技術が最良の場合。または、システムの運営上、どうしても必須になってしまった場合。 その時は、その技術に挑戦することになります。 他社が組み上げたAPIへの連携、知らない言語への挑戦。 これらは、とても苦労するものですが、楽しいものでもあります。 未知の技術というもので苦労するのは当然、それを理解することです。 プログラムを学ぶ方や後輩の方に、伝えているのですが、システム開発で一番大切なことは 調べる能力だと思います。 特にWeb業界は進化が早いものです。培ったものが無意味になってしまうことがあります。 （過去で言えばFlashのAction Scriptとか。。。） その時に大事なのが調べる能力ではないでしょうか？ 私も常にアンテナを立て、最新技術を勉強しております。 常に勉強、それが開発者の生活かもしれません。

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をこれから始める方にお勧めです。

Laravel8がいつの間にかリリースされていましたね。 アップデートは安易に行わないほうが良いかもしれません。 私自身は既存プロジェクトのものにはまだ入れていませんが 新規プロジェクトでも今までの形式とは違うものがあります。 一点紹介させていただくと、Controllersのnamespaceの扱いです。 今までは、そのまま使えましたが、laravel8では動きませんでした。 調べたところ、 app/Providers/RouteServiceProvider.php に下記を加えることで解決しました。 protected $namespace = 'App\Http\Controllers';