信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • テクログ

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =後(プログラム新規作成編)=

    こんにちわ。パグと申します。前編はこちら→https://core-tech.jp/blog/article469/プログラム改修編はこちら→https://core-tech.jp/blog/article473/私はWEBサイト制作においては、プログラム改修よりもプログラム新規作成の方が、作業ハードルが低い様に感じます。理由としては、既存システムの影響範囲調査があまりないためです(新規だから影響箇所が少ない!)。既存システムに新規にページを作成する様な作業が、特に楽な作業に感じます。一方で、全て1から作らなくてはならないので、ルーティン化されていないときついのでは、と感じます。もしあなたが新卒、新人1〜2年目で、ページの新規作成を命じられた場合に何からしたら良いのかわからなくなってしまったら、「詳細設計」を順番に行ってみてください。1.自分の作成予定ページの動線を知る自分が作成するページはどこから入ってくるのかを理解します。表示画面がPOSTでくるのか、GETでくるのか、トップページなのか複数ページなのか、検索結果ページなのか・・・色々なパターンがあるかと思います。そして、入力、確認、完了の様な登録系の処理なのか・・・検索、検索結果の様な表示系の処理なのか・・・を整理し、自分の画面の遷移図を書いてみます。遷移図には書き方が色々ありますし、お作法があるチームもありますので、何も参考になる資料がない場合はもはや手書きでも良いと思います。例えば、簡単に書くとこの様な形になります。・遷移元 → 入力(新規、または更新) ←→ 確認 → 完了・遷移元 → 検索 → 検索結果 → 詳細ページ2.自分の画面の対象となるデータを知る登録系画面の場合は、データを登録するTBLの設計を行います(基本設計が終わってから作業を依頼される場合は、すでに終わっていることも多いフェーズです)表示系画面の場合は、取得元を調査します。ここでPGがすることはSQLを先に考えてしまうことです。Model設計(すでに存在する場合は、メソッドの設計)です。例えば以下のようなことを考えます。・新規登録の場合はどんなカラムが必要か・更新処理ではどのカラムを更新するのか・取得処理の場合はリレーションや、取得条件などは何か、何をInとして、何をOutしたら良いのかSQLが苦手という方によく出会います。DBによって一回でとるのか分けてとるのか、SQLの書き方も様々ですが、取得系処理のSQLが苦手な人は、どんな結果になっていて欲しいのか完成系のTBLを想像してからSQLを書くと頭が整理されるのではないかと思います。まずはSELECTで取得するカラムを想像します→次にWHEREやJoinの条件を考えます。3.機能の設計を行います。ここに関しては改修編と同様ですが、とにかく細分化すること。自分が書けると思われる単位までの細分化です。この様な形で大枠を決めたら、とにかく作業を細かい単位に分割していきます。詳細設計とか言われたけど、何からしたらいいんだ・・・ってなる人は、イベント単位で考え始めると、楽かな、と思います。クラサバ型にせよ、スタンドアロン型にせよ、イベントがあって処理があるので・・・何から書き始めたらいいの?と設計に混乱する人は、とりあえずその機能のイベントトリガーが何かを考えて、そのイベントに対する処理を考えるのが良いかと思います。バッチ処理なら、呼び出された時、画面処理なら、ユーザーの動作や表示されるタイミングです。・初期表示 ・Analyticsやメタタグなども確認する・POSTまたはGETでデータ受け取り・データがある場合→編集画面・データがない場合→新規画面・データのValidation・加工処理→エラーの戻し方・画面の遷移・画面の表示の仕方・Xを押下・・・・Xを変更・・・このようにイベントが大枠で、そこからの細分化を考えるとスムーズかなと思います。ちなみに、単体テスト仕様書もこの様な形で書くとわかりやすくなります。4. 詳細の設計ができたらコードを書きはじめます順番に作っていきましょう。表示させて、HTMLを作って、中身を書きます。・ルートを作る→URLを打ち込むと、空のController,Viewが表示される様にする・ViewにHTMLを書き込む→この時呼び出すCSS,JSなどを考えます・Conotllerを書き込む→機能設計通りにかく→Modelとつなぐ5.詳細設計を修正し、テスト仕様書を書くこの辺りも改修と同じく、テスト仕様書を書きながら、想定通りになっていない箇所を修正していきます。自分で、正常、異常系など含めてテストが一周できるくらいになっていればCD完了です。この時に、想定外エラーやXSS対策、CSRF対策などできていたらより素晴らしいです。業務システム系の開発の場合はCD完了って言ったのに、バグが出てる状態でテストチームに回したりするとめちゃくちゃ怒られます。最後に新人の人が初めての新規作成を命じられて、いきなり放置プレイする現場にはなかなか出会ったことがありませんが、何も言われないからといって「これでいいのかな?」と思いつつ進めるのは、オススメしません。・遷移図、TBL設計、機能設計ができたら、PM(PL)に確認する・一つのActionができたところでPM(PL)に確認するといった感じに、確認しながら進めていくと、完成後大幅に戻されることが少ないのではないかと思います。プロジェクトリーダーも、プロジェクトマネージャーも作業を振っている以上は仕様確認を何度もされることに、嫌な顔をしないはずなので、「これでいいのか」と何度も確認しながら作業していきましょう。口頭ベースだと確認に応じてくれない、リーダーの時間が取れないことも少なくはありませんが、質問の方式を変えてみると良いのではないでしょうか。例えば、表にまとめて、まとめて見てもらうとか、設計書のXXのXXが・・・と資料を渡すとか、色々方法はあります。工期に余裕のある現場であれば、先にテスト仕様書(コード)を作成してから、CDを行うとより精度を高めることができますので、オススメです。「新人の時にすればよかったこと」は、きっと3年経ってから気付くことが多くの人にあるかと思いますが、それを初期の段階でできていると、きっとこの先の自分が楽になることでしょう。以上です。ではまた。
  • テクログ

    ソースコードにおけるエントロピー増大則

    「ものごとは秩序だった状態から無秩序な状態へと変化していく」という意味でエントロピー増大則という言葉を使ってみましたが、正確には誤用です。ただかっこつけたかっただけです。以下、エントロピーという言葉を「乱雑さ」という意味で使います。どうも!今年の4月に入社したわいです。ブログを書くことから逃げ続けていたのですが、向き合います。しかも、テクログ!!!今回は粋なタイトル通り、ソースコードのエントロピー増大について書いてみたいと思います。仕様追加や変更などで、ソースコードのエントロピーはどうしても増大します。ここで、このエントロピー増大を少しでも小さくする方法をプログラミング歴1年未満の青二才が提案します。(※あてになりません)それは、「人間が読んで、自然な処理の流れになっているか」を意識してコーディングを行うというものです。「自然な」というのがすごい抽象的ですが、処理を上から順に言葉にしていき、それらを繫げたときに不自然でないかということです。これができていると、次に読む人に与える誤解が少なくなり、コーディングの意図も伝わりやすくなると思います。つまり、ある人がそのソースコードに何か処理を追加しようとしたとき、「この処理を追加するには、ここ(この行)しかないな」と誘導できるようなコードを書くことができればGOODです。これができると、追加や変更を加えてもソースコードがそこまで複雑にならない、つまりエントロピーの増大を小さくすることができると思います。具体的には、いろいろあると思いますが、とりあえず変数のスコープ(ソースコード上で見える範囲)をなるべく小さくするように心掛けると良いと思います。変数のスコープを小さくすると、次の開発者の変更箇所を限定できます。また、スコープを小さくするために、適度に関数化することで、処理の流れの見通しが良くなります。ただ、なんでもかんでも関数にまとめるのではなく、処理のフェーズ(深さ)を意識して、適度に関数に分ける必要があります。このように偏った意見(特に、具体例)でしたが、新卒プログラマーということで許してください。他にみなさんがコーディングの際に意識していることがあったら、是非教えてください!!以上、わいでした。健闘を祈る!!
  • テクログ

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =後(プログラム改修編)=

    こんにちわ。パグと申します。前編はこちら→https://core-tech.jp/blog/article469/今回は新人プログラマーが「WEBサイトの改修」を命じられた場合の、具体的な作業工程を書きます。もしもあなたが1〜2年目の新人、新卒で、作業をまとめて大量にふられたときに、何からしたら良いのか、わからなくなってしまったら、「情報を整理すること」から始めてください。1.調査をするメモ書きなのか、きちんとした仕様書で来るのかは不明ですが、仕様の確認フェーズでは、・修正をする範囲を洗い出す作業・QAを洗い出す作業の2点を行います。例えば、このページにバナーを追加してください、といった作業の場合・・・・PC/SPなど両UAに入れるのか?・類似画面がないかを確認します。画面名指定のない場合は同じような画面がないか、などQAとしてリーダーやお客様に確認します。例えば、このページのこの情報を削除してください、といった作業の場合・・・・その情報はTBLから出力されているのか、ベタで書いてあるのか・TBLから情報を出している場合は、使用しているカラムや文言で、プロジェクトファイル全体をGrepし、影響範囲をメモなどにまとめておきましょう。そして、その内容に誤りがないか、QAとしてリーダーやお客様に確認します。紐づく情報でGrepしたり・・・、類似Contollerを探したり・・・それらをまとめてQAで出し、自分が実際作業に入る前に聞きたいことをまとめておきます。ここまでが調査のフェーズです。2.詳細設計をする通常、詳細設計の前に基本設計や方式設計などをすると思いますが、今回はPG向けに記載しているため、事前にそれらが完了していることを前提に書いています。設計工数を取ってくれるチームの場合は、設計書のテンプレートがあると思いますので、それに従って行いましょう。設計工数をくれないような小さな作業の場合は、修正対応するContollerやClassに、コメントで作業をかいていきます。//XXXModelを呼び出す//Dataを加工する//Viewに渡すなどのコメントを記載したら、もっと細分化します。//XXXModelを呼び出す//Model内のメソッドの In(変数はXXID)//Outはどんな形か //Notfoundの場合はどうするか//Dataを加工する//1の場合はXXという文字列にする//2の場合はXXという文字列にする・・・//Viewに渡す//渡す変数が未使用か調べる//どのような形で渡すか・・文字列なのか、配列なのか、オブジェクトなのか・・・まとめて考えて混乱する場合は、とにかく細分化していきます。特に良く見るのが、AJAXの機能を書こうとして混乱している人です。AJAXの場合、JS、PHP(などのサーバーサイド言語)、HTMLと分かれているので混乱するかと思いますが・・・こんな風に分割します。HTML・どんなタグがトリガーになるか、Classなのか、Idで呼ぶのか、どんなイベントか・どこに値を戻すのか、Divなのか、Spanなのか、それとも何かの子NodeなのかJS・イベントをかく、ボタンクリックなのか、値変更なのか・イベント詳細を書く、Inは何かOutはどうしたいか、GetなのかPostなのか、どのURLに渡すのか・想定する文字列が戻ってきたら、どこのタグに出力するのかPHP(サーバーサイド言語)・PostまたはGetでなにを受け取るのか、それとも受け取らないのか・受け取った値をどうするのか(例えばModelなどを呼び出し値を取得するとか)・Outするときに加工するか(RestContollerなどの場合はResponse戻しやEchoしないと出ない場合などに気をつける)上記を順番に書いていき、自分が理解のできる「最小の処理」まで分解します。基本的に「代入とIF文と繰り返し」が書ければほとんどの処理がかけます。どんなに大きな案件も、代入とIFと繰り返しで成っています。(これはあくまで自論です。)なので、新しく触った言語で一番最初に覚えることは、代入方法、分岐の書き方、ループの書き方です。3.細分化された単位にPGをあてていく細分化すると、何度も書いているような処理は、関数にしたほうがいいな、とか細かいところが見えてきます。あとは、書いたコメントと同じ処理をPGで1行1行書いていくと、作業が完了します。このときに絶対に焦ってはいけません。焦って色々な方向に気を散らすと完成しないので、自分が最小化させた単位でかける部分だけをどんどん書いていきます。うまく書けない部分は飛ばしても良いのです。4.細分化した単位でテスト仕様書を作成する単体テストっていうのは、PG単位でのテストです。手動でやってませ〜んとか言わない。そいうことじゃない!!プラスで、修正していない範囲のテストができていれば完璧です。テスト仕様書を書きながら、うまくできなかった部分や、考慮が足りない部分を修正して、CD完了です。最後に詳細設計の工数をくれない案件も少なくはないですが、いきなりプログラムを書き始めるよりも、コメントでも良いので、詳細設計をしたほうが、結果的に戻りが少なく、矛盾が少なく、工数的には短く済むので、案件をもらうととりあえずパニックになる人は、調査と詳細設計をぜひやってみていただきたいと思います。次回は新規作成編を書きます。ではまた・・・。
  • テクログ

    PC交換

    来年windows7の更新期限が終わるのでPC入れ替えに大忙しです。ギリギリ使えるwindows7はアップデート作業を行っている最中でその他のPCは入れ替えの為の打ち合わせが始まった。会社単位だと20~等台数が多いのでインストール作業やバックアップ作業で大忙しです。しかし費用面がかさむので急いで必要がないPCを後回しにするなど問題は山積みです。しかし、銀行系を扱うPCはそうはいきません。銀行のHPにwindows7だとダメとか色々あるので規格にあったものでないと業務に支障が出る為細々修正をするよりも買い換えた方が無難です。windows10マンスリーアップデートもあり、すでにwindows10をいれているPCもアップデートの必要がありますのでそちらも平行作業ですすめています。しかし、数台がインストールに失敗し調べた結果1つに絞って入れないとうまくいかない事もあり時間をとられました。アップデートはお早めに。
  • テクログ

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=こんにちわ。パグと申します。最初に、簡単に自己紹介をすると、私は新人PGではありません。SIerに出向して5年ほどはスタンドアロン型のシステム開発をしていました。WEB未経験から、WEBサイト制作をメインとしているコアテックに転職して、7年経過するSEです。そんな私は、最近新人PGの進捗管理をする機会が多いのですが、手が止まってしまう新人が多いのを目撃して、また、自分も同じように新人の頃、手が止まることが多かったので、あの時、こうしてれば・・・と思ったことを前半後半に分けて書いてみました。仕事って一言で言っても様々で、ツールの講習会開いて欲しいとか、システム(サイト)作って欲しいとかSQL書いて欲しいとか、社内環境整備して欲しいとか様々なのですが、今回は、WEBサイト制作に関して、自分の中でルーティン化しているものをまとめます。(事前準備)案件アサイン前に、その企業(チーム)の環境などを展開されると思います。私の場合はどの現場(チーム)に行く場合も大体その現場の言語やツール関連の本を2〜3冊、知らないフレームワークの場合はマニュアルをざっくりと読んでから、そのチームに参画していました。1、まずは改修、新規作成のスコープをはっきりさせる今渡されている作業が、細分化されているものの一部なのか、この案件の全てなのか、つまり、これを作ったら案件完了なのか、自分が作っても他の人が終わってなければ完了にならないかを認識します。初めての現場でドキュメントや引き継ぎ事項に「納品物」がはっきりと書いてない場合は、直接関係者に聞いておきましょう。これは会社によっても会社内のチームによっても異なるからです。(納品物の例)・ソースだけで良い→ソース管理ツールにPUSHしたら終わり→物理的にファイルが欲しい→サーバーにアップして欲しいなど・テスト仕様書も欲しい→Excelで欲しい→特定のフォーマットで欲しい→スクリプトが欲しい・テスト仕様書にエビデンスも欲しい→同上など、納品物も案件によって異なります。2、自分の担当部分のスケジュールをはっきりさせましょう渡された期日が、コーディング完了日なのか、テスト完了日なのか、リリース日なのか、顧客引き渡し日なのかは出向先やチームによって異なりますが、勝手にスケジュールを引いて間に合わないとなると困るので、自分の作業を完了し、渡す日がいつなのかって部分を、PM、PLまたは顧客ときちんとネゴって文章に起こしておくといいと思います。文章に起こすっていうのはチャットでもメールでもいいんですけど、口頭でやり取りした場合言った言わない問題が発生しないようにするため、口頭で話をした後に関係者をCCに入れたメールなどで再確認した方がいいです。それは相手を信頼していないからではありません。自分自身で期日が間違えていないかを再認識するためでもあります。期日を入れる例は以下のとおり。——X月X日X時 コーディング、単体テスト完了X月X日X時 受入テストX月X日X時 リリース日——3、大枠の作業の洗い出しをしますすごいざっくりとした作業工程の洗い出しをします。今回はWEBサイト制作のPGのフェーズなので、簡単に以下のような行程に分かれるかと思います。・詳細設計・CD→作成する機能の大枠を考える・単体テスト・結合テスト4、現行システムを把握するお見積もりを作るような立場の人だと、現行システムを把握するのは、スケジュールを切る前にやりますがPGでしたら、案件開始前に把握できれば良いかと思います。運用案件の場合、渡された仕様書以外に修正が必要な点がないかを把握することが大事です。それによりスケジュールの達成可否が大きく変わるためです。・現行システム全体を把握→このフェーズでは全体像をざっくり捉えるのが大事です。→インフラ構成だとか→全体画面数だとか→TBL構成だとか・機能追加部分の現行ソースを読む→コード規約だとか→命名ルールだとか・案件進行ルールを把握しておきます5、終わるのか終わらないかを考えてみる。ここまでで、X月X日までに何を作らないといけないかってところが割と具体的になっています。スケジュールが鬼のようにきつい案件も勿論たくさんあります。その場合は、「できない」っていう勇気が大事です。私が経験した企業は10社あるかないか(上場企業から20名程度の小さな会社まで規模は様々)ですが、どの企業様でも、仕事なんだからできないっていうな、とか体育会系的なことを言われることはありませんでした。伝える際には、・ここまでなら終わる・X日あれば終わる・なぜ無理なのかを具体的に伝えてください。ただ「こんなんおわんないっす〜」では伝わらないのでダメです。これとこれは終わりますが、この部分だけ、後出しにしてくださいなどの提案がないと、PL(PM)もじゃあどれくらいやってもらえるのかな?というのを想像できないためです。ちなみにこの工程は、残業時間を含めない状態で考えた方がいいです。残業すれば終わる工数というのは、すでにスケジュールに無理があるからです。————————最後にプロジェクトのリーダーは作業をふるときに通常、作業が終わらないことを想定して、保険をかけながらスケジュール作成しますので、自分で無理かもしれないと思ったときには、正直に伝えてもらったほうが予定を組みやすいです。仮に、できる!と思って作業を始めても、終わらないと思った時点で、速やかに伝えることが大事です。渡された仕事が仮に全て終わらなかったとしても、自分でそれを伝えられていれば、あなたの評価が下がることはありません。周りの人が巻き取ったとしても、それはあなたの責任ではありません。新人のうちは、他者と協力しながらでも良いので、自分でできることを、できる限り順番にこなしていく、というのを意識して仕事をします。もちろん、そんなに優しくない企業もシチュエーションも沢山あると思いますので、思い通りにいかないことも理不尽なことも沢山ありますが、誠意を持って対応することで、理解してくれる上司や同僚は、多いと思います。次回は具体的にコーディングや設計に入るところを記載していきます。ではまた・・・。
  • テクログ

    IT業界で長年やってるのに、なんなのか答えられない単語について語る2

    こんにちわ。パグです。今日もモヤモヤ理解してるけど説明できない内容について語ります。1はこちら→プロトコルについてhttps://core-tech.jp/blog/article445/今日は「セッション」についてです。OSI参照モデルのセッションではなく、HTTPのセッションです。はい、じゃあ説明していきます。セッションってなんなの?って聞かれた時になんて答えますか?セッションとはとかで調べたり、先輩に聞いたりして、・通信に先立って、2台のホスト間で必要なデータをやり取りすること・WEBページを開いて離脱するまでの1連の流れのこと(参考リンク)https://www.seohacks.net/basic/terms/session/https://wa3.i-3-i.info/word1791.htmlこういった説明をよくされるのではないでしょうか。この二つは、実は同じ話をしているのですが、内容を理解していないと全然異なるものに感じます。そのためセッションという言葉の意味が曖昧になります。セッションを理解する前に、WEBブラウザが表示されるまでの仕組みについて説明します。WEBサイト、というのは、ユーザー(のPCやスマホ)からどこかのWEBサーバーにリクエストを投げます。WEBサーバーからはこのリクエスに応じたページを返信して終了します。例えば、私が、どこかのサイトで買い物をしたいとします。ブラウザにURLを入れるか検索サイトでアクセスすると、このサイトのトップページが表示されます。そこで買い物をする場合にどういったやり取りがなされるかというとーーーーーーSTARTーーーーーー私:トップページが見たいサーバー:ほらよ(トップページ返す)ーーーーーー私:これ買いたいサーバー:ほらよ(カート画面返す)ーーーーーー私:クレカはこれねサーバー:ほらよ(決済画面返す)ーーーーーー私:購入できたから、画面閉じるーーーーーーENDーーーーーーWEBは通常このような流れで、サーバーからは「ほらよ」と画面が返された時点で一回毎のやり取りは終了します。ここに今どういった状態であるかを保存する機構を持たないためです。でも上記のような買い物をしたい、のような動作の場合、トップページからカート画面へ遷移する時に、どの商品を持って遷移したか、とか、決済画面に行く時に、どのユーザーであるのか、などをサーバー側がわかっていないと、適切な画面を返すことができません。ですが、HTTPの通信には、このような情報を保持する箇所がありません(※1)。じゃあ現在の技術ではどのようにして現状の状態を保持しているのかというと、ここでやっと「セッション」がでてきます。「セッション」とは一連のやり取りの中で、今の状態を維持したまま相互に通信されている状態のこと、と理解しましょう。例えば、STARTからENDまでの流れを「1つのセッション」として説明すると、STARTからENDまで私がログインしていて、この商品を買って、このカードで買うという現状状態を保持した状態で、サーバーと私が通信している、この現状状態を保持した状態での通信が1つのセッションです。たまに、セッションをクッキーのようなものやキャッシュのようなものと誤解されている方がいますが、それはクッキーであり、キャッシュであって、セッションは保存するところの名称ではありません(※2)。通信に必要な情報を保持したまま通信を行なっている状態の方をセッションと呼びます。このセッション中に、どこに情報を保存するかというと、通常はクッキー+何か(RDSやKVSやmemchacedなど)またはクッキーに直接本体を突っ込む。または、ファイルで持っている。など色々と種類があります。いずれも、暗号化された状態で、たとえその実体を盗まれたとしても、中身が見えないようにした状態で保存している必要があります。最初に出てきた・通信に先立って、2台のホスト間で必要なデータをやり取りすること・WEBページを開いて離脱するまでの1連の流れのこととはつまり同じことを指していて、どちらの言葉も使って説明すると・・・「WEBページを開いて離脱するまでの1連の流れの中で、通信に先立って、2台のホスト間で必要なデータをやり取りすること」→これが完璧なセッションの説明となります。新人に聞かれた際にはドヤ顔で答えてあげてください。クッキーやキャッシュと混同して混乱している新人さんがいたら、「それはセッションの保存領域のことでセッションのことじゃないからぁ(ドヤァ)」と説明してあげてください。———(※1)ログイン情報とかでない場合は、POST、GETでいけるんちゃうかって考える人もいると思うんですが、今回はあくまで「セッション」の説明だということに注目してください。(※2)今回はsessionStorageの説明ではありません———以上になります。いずれ。また。