Allegro!

JavaやIT系小ネタ、趣味の話まで。

LANケーブルでインターネット速度改善!

皆さんこんにちは、管理人のPaZooです。
私はオンラインゲームをするのでネット速度はかなり重要です。
今よりも速度を出すために色々調べてみていると「LANケーブル」にたどり着いたので、今回はLANケーブルについて調べた内容を備忘録のために記事にしました!

LANケーブルとは

LANケーブルの重要性についてあまり意識されていない方もいらっしゃるかと思います。
実はLANケーブルって、とっても重要な役割を持っているんです!!

LANケーブルとは、優先でインターネット接続をするために必要なものです。
私はPS4でオンラインゲームをするのでLANケーブルが絶対必要です。

一見同じように見えるのですが、製品によってカテゴリ(規格)はもちろん違いますが、素材や形状などによっても性能が変わってきます!

LANケーブルには「CAT5」のように数字がついていて、この数字が大きいほど性能が高いので高速通信回線に対応可能となっています。

カテゴリ(規格)によってどんな違いが出るのか

Gbps(ギガビット)
Gbps(ギガビット)とは、データを通信する単位です。
数字が大きいほど、大きな容量を短時間で送ることが可能。

MHz(メガヘルツ)
MHz(メガヘルツ)は伝送帯域で、データを送ることができる周波数の幅を表しています。
数字が大きいほど、送るデータの量が増えます。

LANケーブルの選び方

快適なゲームやPC環境を整えたいなら「CAT7」以上!

CAT7は通信速度10Gbps、帯域は600MHzに対応しており通信ノイズの耐性が高いです。

そのため、通信速度が速く伝送帯域が高いので高速通信が可能。
オンラインゲームやインターネット通信速度に不満を感じている方はLANケーブルをCAT7にしてみましょう!

速度を重視しないなら「CAT6」でよいです。
CAT6は、通信速度1Gbpsで伝送帯域が250MHzに対応しています。
一般的な光回線の契約は1Gbpsなので、速度を重視せずにインターネットサーフィンや動画配信サイトを楽しむのであればCAT6にすると快適に感じますよ。

ちなみに、CAT6とCAT7の中間性能のLANケーブルとして「CAT6A」もありますよ。

形状の違い

LANケーブルには、「スタンダード」「極細」「フラット」「リール」という形状があります。それぞれの特徴をまとめてみました。

スタンダード

f:id:PaZoo:20200923191340j:plain
スタンダードタイプのLANケーブルは、比較的太い導線が使われています。
ケーブルの断面が丸くなっており、ほかの形状と比べてみるとケーブルが曲がりにくいため長い距離の配線に適しています。
伝送するスピードや安定性に優れているため、通信ノイズの影響を受けづらいのが特徴です。

極細

f:id:PaZoo:20200923191738j:plain
極細タイプのLANケーブルは、スタンダードタイプよりも細い導線でケーブル自体が比較的柔らかい素材のため、曲げやすく取り回しが良いところが特徴。
見た目も細いため、配線周りもすっきりします。

フラット

f:id:PaZoo:20200923192129j:plain

フラットタイプのLANケーブルは、ケーブルの形状が平たくて薄いことが特徴です。
スタンダードタイプと比較すると強度は劣るため、無理に引っ張ったりしないよう気を付けてください。

リール

f:id:PaZoo:20200923192410j:plain

リールタイプのLANケーブルは、使用しないときに巻き取ってコンパクトにできるという特徴があります。
非常に便利ですね!

LANケーブルの長さ

LANケーブルには様々な長さがあり、利用用途により必要になる長さが変わってくるので購入前に測っておくことをおすすめします。

また、ケーブルの導線には「単線」と「より線」の2種類が存在します。

単線:硬く、通信ノイズを受けにくい。
より線:柔らかく取り回ししやすい。

ノイズが発生しやすい20cm以上の距離では単線を、20㎝以下の距離でケーブルを曲げる場合はより線がオススメですよ!

まとめ

管理人は正直、違いが分からずに「とりあえず買っとけ!」くらいの認識でしたが性能が全く違うことにびっくりしてしまいました(笑)
通信速度が遅いと感じる方は、自分が契約しているインターネット回線の通信速度をチェックして目的に応じたLANケーブルを購入しましょう!
参考になれば幸いです。
ではまた!

【感想】仕事の速度と精度を上げるために「仮説思考」を読んでみたら目から鱗だった話。

皆さんこんにちは。管理人のPaZooです。

エンジニアとして働き始めて早数年が経ちますが、仕事に向かっても時間ばかりが経過してしまい成果が思うように出ないことが多いのが悩みでした。
そんなときに出会った本が「仮説思考 BGC流問題発見・解決の発想法」です。この本を読んだ感想について簡単にまとめていきます! 

本書の要点

1. 仮説とは、情報収集の途中や分析作業以前にもつ「仮の答え」のこと。そして、仮説思考とは、情報が少ない段階から、常に問題の全体像や結論を考える思考スタイル、あるいは習慣というべきもの。

2. 仮説思考を身に付ければ、わずかな情報でも初期段階で分析することができる。

こんな人におすすめ

  • 物事を始めるときに情報を集める人
  • 失敗を恐れてしまい、完璧な答えを出したがる人
  • 分析するにも時間が足りなくなってしまう人

どんな本なの?

迅速に問題を発見・解決していくための思考法についての本です。例えばですが、あるテーマに取り組むときを考えてみてください。
まずテーマに対して網羅的に情報を集めるとなると、資料の収集に時間がかかったり情報洪水に飲まれてしまうケースがあるため、結果的に仕事で思うように成果を上げることが難しくなりがちです。
そこで、「まずは少ない情報から仮説を立てて検証するというスタンスで仕事を進めていくと素早くテーマの本質に迫ることができるようになるよ!」というのがこの本から学ぶことができます。

仮説思考を身に付けるメリット

ここで、私の失敗談をお話したいと思います。

現場である企画を提案するために、プレゼン資料を作ることになりました。
まずはあらゆる情報を集めて資料を作成しようとしたのですが、膨大な情報と分析に時間がかかってしまい結局最後まで分析できずにタイムアップしてしまいました。

今となってはいい経験でしたが、思い出してみるとかなり恥ずかしいです。
きちんと目的を決めないまま仕事に取り組んでしまったので、成果としてどのような解決策を出す必要があるのか結論を導き出せずに終わった苦い思い出です。。。

この時に、仮説思考で結論から考えれば良かったのです。
具体的に言うと、先にプレゼン資料の目的を決めて(例えば顧客を増やす等)、それの裏付けになりそうな情報を収集する。

こうすれば締め切りまでに満足のいく資料を作成することができたかもしれません。また、裏付けが取れる情報がなかった場合すぐに別の仮説を立てて検証していく時間もあったと思います。

仮説思考を身に付けることで得られるメリットは、問題を素早く捉え解決に対して仮説を立てながらスピーディーに検証を行うことで結論を出す速度が早くなることだと私は思います。

私の最強上司も「資料で何を伝えたいのか、まずはストーリーから考えて!」と言われてましたが、今思えばこの発言そのものが仮説思考だったのです。さすがだなあ。

本を読んだ感想

個人的に、とても満足いく書籍でした。
仕事の課題や問題を解決するために問題点をすべてピックアップするのではなく、答えを「仮定」することで仮説に対して検証を進めていく
これを繰り返して行くことでよりスピーディーに、より質の高い解決を実現することができます。

私自身、この本と出会うまで「網羅思考」タイプの人間だと自負していました。
まずは情報から!と情報を集めてみたのはいいけれど、問題点をすべてピックアップしていくとどの問題に対してアプローチをかけていくのか意思決定が遅くなるため成果を出すのに時間がかかりがちでした。

しかし、この本と出会ってからというもの、一つの仮説に対して検証をするために情報を集めてみたりヒアリングしたり検証を繰り返すことでブラッシュアップされていきよりスピーディーに、より生産性を向上させることができつつあると感じています。

出会ってよかった。ありがとう、仮説思考!

まとめ

実例も多く取り上げられており、実践的に使える知識を学ぶことができる「仮説思考」をご紹介させていただきました!
ちなみに、同じ著者より「論点思考」という本も出ておりましてそちらも非常にお勧めですよ!!
この投稿を機に、本が気になった方はぜひ読んでみてください!

見てる割合と反応している割合がほぼ1割なので自分の投稿について整理してみた話。

どーも皆さんこんばんわ。管理人のPaZooです。
さて、今回書いていく内容は「閲覧数から見るアクション率について考えてみた」というお話です。

気になった背景と概要

今回の気になった背景として、自社用SNSを活用している中で閲覧数から見たときのアクション率を算出しているのですが毎回1割なんです。
その数値を見るたびに思うのです。なして1割なん???と。

約500名閲覧したら50名は反応してくれます。もちろん投稿するスレッドが違えばリーチ数も変わってきますが、ここでは大多数が閲覧できるスレッドでの閲覧数をリーチ数としています。
下記の計算式はアクション率を算出する式です。

アクション率=(いいね!数+コメント数+シェア数+クリック数)÷リーチ数

ここで言うアクションとは、「いいね!」やコメント、シェア数、画像やURLなどのクリック数のこと。つまり、投稿に対するリアクション(=ユーザーが起こした行動)ということです。
また、計算式の最後にある「リーチ数」は、実際に投稿を見た人数を指します。投稿がどれだけユーザーの行動を喚起させたのかを知る目安になるので、投稿内容の改善や検討材料として役立つことが多いです。
つまり、アクション率を見れば、リーチされた人の何割がアクションを起こしたのかがわかりますね。ちなみに平均アクション率は0.5%~2%なので、自分の投稿に対するアクション率はやや低いように思えます。

アクション率から自分の投稿について考えてみた

「なんでアクション率なんか気になるの??」という声が聞こえてきそうですねw
なぜ気になるのかですって?そりゃ皆さんに良いコンテンツを届けるためですよ!…というのも理由としてありますが、自分の投稿が周りに対してどんな影響を与えているのか気になるからです。

周りがどんな反応をするのか考えずに投稿するのは、あまり意味のないことのように感じます。
アウトプットの練習だったり、ネタや知識を共有することはエンジニアとして大事なところ。しかし、ただ発信するだけではアウトプットとは言えないように思うのです。(最近思ってきただけなのですが…w)

自分が得た知見に対しての感情や経験をプラスαすることで、ほかにはない素晴らしいコンテンツになるのではないかと思います。

アクション率を上げる方法をまとめてみた

アクション率を上げるには、結論からいくと「ユーザーを喜ばせる良質な投稿」と「アクションを起こしやすくする仕組みづくり」を心がけることだと考えました。

やっぱり興味のある投稿だったり、一目見て何を伝えたいか分かりやすいほうがいいですよね!

ユーザーを喜ばせる良質な投稿をするためには?
  • どんな人に伝えたいのかペルソナの設定を行うことで、ニーズを捉えやすくする
  • 一貫性のある投稿でファンの心を掴む
  • 飽きられないコンテンツ発信をする


技術寄りな投稿が多いのですが、技術に興味がある人もいれば興味がない人もいるのでアクション率が低いことは見て取れます。
飽きられないコンテンツを発信するというのは、動画を取り入れたり旬のネタを取り入れたりすることだと解釈しています。
誰にでもウケるコンテンツを作るのはとても難しいですね…。

あと、考えたのは「私のことを知らない人にとってアクションすることは難しいのではないか」ということ。私自身のことを知らない人からすれば、どんな人なのかも見えない状態でアクションを起こそうとは思わないなあと。。

私からアクションを起こすことで、向こうに知ってもらうチャンスが来るというのも今回の分析から見えました。

まとめ

もっとジャンル別にアクション率を取れば細かい分析ができそうなので、今後も分析していきたいと思います!
皆さんの中で「投稿するときはこんなことを気を付けている」というのがあればぜひ教えてください!

それでは。

July Tech Festa 2020に参加してきたのでレポートがてら書いてみる

皆さんこにゃにゃちわ、PaZooです。
四連休最終日ですね。私は応用情報の勉強を進めていますが、離散数学がさっぱりです('ω')

今日はインフラエンジニアの祭典 July Tech Festa 2020参加レポートと題してブログを書きました!
いや~~本当に良かった。めっちゃ勉強になったので、ぜひ次回も参加したいです。

はじめに

エンジニア歴3年生なので、インフラエンジニアの祭典 July Tech Festa 2020に参加してきました。

新型コロナウイルスの懸念もあり、なんとフルオンラインでの開催!場所や時間も制限されないような環境が整っていたので個人的にはかなり良かったです。アーカイブYouTubeで配信されているので当日参加できなかった方はぜひご覧ください!
(可能であれば、今後もYouTube配信をやっていってほしいです…!)

さて、今年のテーマが「Extend Your Engineering Life」ということで、カテゴリー的には自分のキャリア観についての話が多かったように感じました。
その中でも特に印象に残っている方のレポートを書き連ねていきます。

常松祐一さん:組織に良い開発文化を植え付ける「Software Engineering Coach」という役割

常松さんのお話は、特に開発者とPMに聞いてほしい内容でした。

「良いソフトウェア開発」から考えさせられ、良いソフトウェア開発を行うためにはどうすれば良いのか。
その中で、より良い開発プロセスを組織に植え付ける役割である「Software Engineering Coach」に出会ったことで自分が組織の中でどう立ち回るべきか考えたこと。

TeachingとCoachingの違いも共感の嵐でした!

  • Teaching:上下の関係性で答えを教えるため、相手は受動的になる
  • Coaching:対等の関係で相手の中にある答えを導くため、相手は能動的になる

確かにそれ。とてもわかる。
とはいえ自分がCoachingできているかと聞かれると首を縦には触れないので精進あるのみです。トホホ。

常松さんのお話の中で一番共感したのは「PMだから~だからとか役割に関係なくアイデアを提案して良い開発プロセスを根付かせていく」というところでした。

シンプルに問題をとらえ、解決する。そして、日々の業務の中でイデアを見つけみんなに共有していく。

このサイクルは開発者にとって前に前に進んでいけるような言葉でした。強く残っています。がんばろ。

↓SpeakerDeckのリンクはっておきます。

speakerdeck.com

小倉真人さん:組織企業グループを超えたエンジニアのつながりを広げるイベントをしている話。

小倉さんのお話は、「エンジニアのイベントについて」でした。
NTTグループで勤めていらっしゃる小倉さんが、エンジニアのための勉強会を内部から外部に向けて開催するときにどんなことを考え、どんなことに注意を払っているのかを簡潔にお話してくださりました。
NTTグループといったら知る人ぞ知る大企業ですが、いくつもの事業に分かれていて担当している内容も全く異なるそうです。
同じ会社なのに接点も交流もない…そんな中で作られたのが「NTT Tech Conference」や「NTT Enginier’s Festa」だそう。

会社で勉強会は行われず、支援も期待できない。
そんな中で自分たちの知識をより広げ、交流を行うためにイベントを開催する運びになったとのことでした。

私自身も社内でイベントを開催する機会が多いので、小倉さんのお話はとても参考になりました。

  • 目的
  • 開催する時期
  • 予算
  • コンテンツ
  • 参加者へのアンケート内容の検討
  • 運営スタッフでの振り返り

上記の内容はかなり共感するところがありました。

特に、参加者へのアンケート内容の検討や運営スタッフでの振り返りというところは現状できていないところでしたので次から真似してみようと思います!

↓SpeakerDeckのリンクはっておきます。

speakerdeck.com


まとめ

今回、初めてJTFに参加しましたがとても刺激を受けました。
色んな人の知見を聞いて自分の経験にしたり、作成された資料の構成を見たり話し方を見てプレゼンテーションのやり方を盗んだりかなり勉強になるので、やっぱり定期的にこんな感じのイベントに進んで参加していきたいと思いました。

業務ばかりだと、どうしても周りが見えなくなってしまうので自分のエンジニアリングを鍛えるためにもこれからも学び続けます!

【SQLserver】大量のデータを爆速にinsertする方法

こんにちは、管理人のPaZooです。

性能調査など負荷試験を行う時に、SQLServerのテーブルに大量のデータをinsertするケースがありましたのでその時に調べた内容を記事にしました。

データを大量に作成するとなると時間がかかって大変でしたが、とても良い経験になりましたのでお役に立てれば幸いです。

テスト環境を整える

まずは実行する環境を整えます。

【実行環境】SQL Server2019 Express(64bit)

サンプルデータベースの作成

テスト用にまずはデータベースを作成します。データベースの作成は下記の記事が分かりやすかったので、ぜひ参考にされてください。

sql-oracle.com

私はサンプルデータベースとして、「mstDB」を作成しました。

サンプルテーブルの作成

では次に、サンプルデータを格納するためにサンプルテーブルの作成を行います。

USE [mstDB]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [usrDB].[test_usertbl](
	[id] [int] NOT NULL,
	[Name] [nchar](15) NOT NULL,
	[RegDate] [date] NOT NULL,
 CONSTRAINT [PK_usertbl] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ループを使ってレコードを作成するクエリ

まずは単純にループするだけのクエリを作ってみました。

    SET NOCOUNT ON 
        DECLARE @insertNumber INT
        SET @insertNumber = 0
        WHILE @insertNumber < 1000000
        BEGIN
                INSERT INTO [mstDB].[usrDB].[test_usertbl] (
					[id]
				  ,[Name]
				 ,[RegDate]
				 )
                VALUES
                        (@insertNumber , 
     'test'
    ,  GETDATE())
                SET @insertNumber = @insertNumber + 1
        END

 ループ処理でデータをinsertした結果、なんと5分もかかりました…。

100万件で5分なので、もし1000万件のレコードを作成するならば単純に考えても50分はかかります。

さらにカラム数が多い場合やデータ件数が増えてしまうと、より性能面で不安を感じますね…。こんなクエリは検証環境でも実行したくありません。。。

再帰SQLで大量のテストデータをinsertする

今回、再帰SQLを使ってinsertしてみました。

再帰SQLとは、前に行った処理の結果を利用し同じ処理を繰り返す場合に使われます。

今回はwith句を使っています。with句とは、メインクエリの中で同じクエリを何度も呼び出す場合に使用されます。

下記のクエリを管理人の環境で実行したところ、20秒ほどで100万件のデータをinsertできました!

USE [mstDB]
GO

DECLARE @insertNumber Bigint    -- INSERTする行数
SELECT @insertNumber=1000000;  -- 100万に設定


WITH Base AS
  (
    SELECT
      1 AS n

    UNION ALL
    
    SELECT 
      n + 1
    FROM
      Base
    WHERE
      n < @insertNumber
  ),
  Nums AS
  (
     SELECT
       Row_Number() OVER(ORDER BY n) AS n
     FROM
       Base
  )
  
  INSERT INTO [mstDB].[usrDB].[test_usertbl]
  SELECT
      n
    , 'test'
    ,  GETDATE()
  FROM
    Nums
  WHERE 
    n <= @insertNumber

OPTION (MaxRecursion 0); -- 再帰SQL再帰回数の上限を無制限にする

f:id:PaZoo:20200607194035p:plain

ちなみに再帰SQLでは、再帰回数を指定していない場合に無限ループを考慮し、再帰可能上限値の規定値が100となっています。

ですので、上限最大値を変更するためには「MaxRecursion」を指定してください。

MaxRecursionで設定できる値は、「0」から「32,767」までとなっており「0」は上限なしです。

今回は100万件のレコードを作成するために、インクリメントさせてます。

まとめ

100万件のデータを扱うとなると性能面を最も気にしなきゃいけないので、今回調べた再帰クエリはとても勉強になりました!

データを更新するときにも使えるので、大量のデータを扱う際はぜひ再帰SQLを使ってみてはいかがでしょうか?

 

【DBflute】DBの変更に強いDBflute!特定のTBLだけ実行したい場合の方法!

皆さんおはようございます、管理人のPaZooです。

緊急事態宣言ももう少しで解除となりますが、気を引き締めたいところですね。

 

さて、話が逸れてしまいましたが今回は「DBfluteで指定したTBLに対して実行したい時の方法」を書き残そうと思います。

 

 DBfluteとは

DBへの接続をしてくれるORマッパーのフレームワークです。
このフレームワークの特徴として、「DBの変更に強いこと」が挙げられます。

DBのEntityを読み込み、対応するクラスとメソッドを自動生成してくれる優れもの!

DDLを修正することなくレコードの取得 や更新、追加、削除を行うことが可能です。

基本的な使い方は、公式ドキュメントが最&高で分かりやすいのでリンクを記載しておきます。

dbflute.seasar.org

特定のTBLに対して実行したい場合

DBfluteの基本的な動きについて先ほど説明させていただきました通り、デフォルトで全てのTBLに対して自動生成します。

そんな時に、ある特定のTBLに対してのみ実行したい場合など細かい設定を行いたい場合について手順をまとめてみました。

対象ファイル:databaseInfoMap

スキーマのメタ情報を取得する上での接続情報や細かい設定を行うDBfluteのプロパティです。

DBfluteクライアントのdfprop配下にある「databaseInfoMap.dfprop」という名前のテキストファイルが対象ファイルです。

必須プロパティとなっており、接続情報に関しては"自動生成実行前"に設定されることを前提としています。

ちなみにMap型のプロパティです。

自動生成対象のオブジェクトを記載するのは、「objectTypeTargetList」というリストを持つプロパティに記載してください。

TBLだけでなく、ViewもTBLと同じように扱うことが可能です。ちなみにこんな感じ。

; variousMap = map:{
    ; objectTypeTargetList = list:{TABLE ; VIEW ;}
}

また、自動生成対象から除外したい場合は「tableExceptList」に対象TBL名を記載してあげると除外されます。

tableExceptListでは正規表現を使うことができるので、非常に便利です。

基本的に大文字小文字の区別はなく、tableTargetList(自動生成対象リスト)に記載されている場合は、tableExceptListに記載しても無効となります。

 

DBfluteは特定のカラムを自動生成対象から除外すれば自動生成されなかったりと、プロパティ設定でかなり自由が効きますので知識として知っておくと開発が楽になりますよ!

まとまらないまとめ

DBflute is God!!!

【SQLserver】トリガーについて

こんにちは、管理人のPaZooです。

トリガーとは、何かのイベントをきっかけに実行される特殊なストアドプロシージャです。

SQLserverのトリガーには、ログオントリガー、DDLトリガー、DMLトリガーの3種類があります。

今回は、トリガーについて調べてみました。

ログオントリガー

ログオントリガーは、ログオン時にユーザーセッションが確立される時に実行されます。

例えば、ログオントリガーを使って「既にセッションが確立されているユーザーが、他のセッションでログオンしようとした場合は拒否する」というようなことが可能です。

DDLトリガー

DDL(Data Definition Language)トリガーは、CREATE・ALTER・DROPステートメントのようなDDLイベントと呼ばれるデータベースのスキーマを変更するようなイベントをきっかけに実行されます。

DMLトリガー

DML(Data Manipulation Language)トリガーは、テーブルやビューに対してINSERTやUPDATE・DELETEステートメントのようなデータの挿入・変更・削除などが起こった時に実行されます。

トリガーを起こしたステートメントと同じトランザクションとして扱われるため、トリガー内でエラーを起こすことによりトランザクションロールバックさせることもできます。

DMLトリガーを使って、データの変更履歴を残したり特定のカラムに対して変更された時に、他のテーブルの値を更新するなどの追加の処理をしたりすることが可能です。

また、INSTEAD OFを指定することで、元の処理の代わりに別の処理をさせることも可能です。

DMLトリガーについては下記記事でご紹介しておりますので、ぜひご覧ください!

(作成中です)