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

お問い合わせ
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です。これができると、追加や変更を加えてもソースコードがそこまで複雑にならない、つまりエントロピーの増大を小さくすることができると思います。具体的には、いろいろあると思いますが、とりあえず変数のスコープ(ソースコード上で見える範囲)をなるべく小さくするように心掛けると良いと思います。変数のスコープを小さくすると、次の開発者の変更箇所を限定できます。また、スコープを小さくするために、適度に関数化することで、処理の流れの見通しが良くなります。ただ、なんでもかんでも関数にまとめるのではなく、処理のフェーズ(深さ)を意識して、適度に関数に分ける必要があります。このように偏った意見(特に、具体例)でしたが、新卒プログラマーということで許してください。他にみなさんがコーディングの際に意識していることがあったら、是非教えてください!!以上、わいでした。健闘を祈る!!
  • テクログ

    Amazon CloudWatch Synthetics(プレビュー)で超簡単サイト監視!?

    マスオです。AWSの進化はどこまでいくのか?某国のビッグプロジェクト受注は逃しましたが...一昨日の公式ブログで気になるサービスのプレビュー公開が書かれていました。Introducing Amazon CloudWatch Synthetics - Now in Previewいわゆる外形監視する場合、お手製の監視ツールだったり既製のツールやサービスを使うことが多いと思います。(ZabbixとかMackerelとかNew Relicとか)あるいは会社によっては外部委託していてアラート条件に合致したら有人でエスカレーションや再起動対応!みたいなのもあったり。単純に死活だけ見たい場合もあれば、レスポンス時間やHTML内容をチェックしたりなど24時間サイトを細かく監視したかったりアクションを色々やれたりできると嬉しいやつですよね。ブログを見る限りでは初期設定は簡単でカスタマイズ性も高そうです。費用面では1回のアクセスで最低0.0012ドルかかるようなので、1分に1回だと6000円くらいかかる?高いか安いか・・・。まだ東京リージョン非対応でプレビューリリースとなっており、・US East (N. Virginia)・US East (Ohio)・EU (Ireland)だけ対応かつ申込みをするところからになります。皆さんも良かったら是非お試し下さい!それではまた!
  • テクログ

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

    こんにちわ。パグと申します。前編はこちら→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つに絞って入れないとうまくいかない事もあり時間をとられました。アップデートはお早めに。
  • テクログ

    AWSが新しいディスカウントプランを発表しました

    こんにちは、おっしーです。皆さん、AWSって使ってますか?だいたいEC2、RDSあたりがよく使われると思うのですが、正直、AWSの料金体系って難しいですよね。予めスペックに対して決まった金額を払うものもあれば、使用した分だけ払う従量課金制のものもあります。小さな規模のサービスを作るなら別ですが、それでもお金がかかるものなのできちんと自分の使用目的と照らし合わせて料金を確認したいところです。そんな中でAWSが新たにディスカウントプランを発表しました!もともとリザーブドインスタンスという料金体系があります。(RI)リザーブドインスタンスというのは、予め一定の額を払っておくと、決まった期間安く使えるよというものです。電車やバスの定期券のようなものですね。そちらに似たものですが、今回2つのプランが追加されました。○Compute Savings Plansリージョンやインスタンスファミリー、サイズなどに関わらず、EC2とFargateが最大66%引きになるプラン○EC2 Savings Plansリージョンやインスタンスファミリーは制限されるが、EC2が最大72%割引になるプラン料金計算をするのは難しく、スマホの各キャリアが打ち出すプランのように複雑ですがこういったものがあると知っておくだけでも幅が広がってより適したプランを選ぶことが出来ますね。無駄なお金は使わない方がいいです。ということで、皆さんも良いAWSライフを!