生成AIを活用したSaaSサービス提供企業

  • Company
    • Company
    • 会社概要
    • グループ会社
  • Service
  • Work
  • News
  • Recruit
  • Blog
  • Contact

ブログBlog

  • ALL

  • お知らせ

  • 技術/デザイン/制作

  • ベトナム

  • ごはん

  • 日常/プライベート

  • 「インターフェースデザインの心理学」読了

    ミステリー小説が大好き竹内です。こんにちは。
    森博嗣の作品が大好きですが最近のはまったく読めていません。

    そんな中、先日、インタフェースデザインの心理学という本を本屋で見かけて購入しました。
    もともとUI/UXには興味関心が強いのでこういった読み物は大好きです。

    書評が出来るほど沢山の本を読んでいる訳でもないですし、知識がある訳でもないのでただの感想になりますが、読み物として非常に面白かったです。
    人間はインプットをどの様に解釈して、脳はどの様に理解し、それをどの様にアウトプットするのか?そんなことが各章毎にテーマ別に書かれていますので、興味のある章だけつまみ読みする事も出来ます。
    自分が特に面白いなと思ったのは以下の項目でした。

    031 人はシステムを使うときメンタルモデルを作る
    043 ある事態に対する注意力は頻発が予想されるか否かで決まる
    052 ドーパミンが情報探索中毒を招く
    074 データより物語のほうが説得力がある
    087 エラーはすべてが悪いとはかぎらない

    それぞれに説明すると長くなってしまうのとネタばれになってしまうので解説はしませんが、どれもこれもなるほどなぁと思える内容でした。
    「当たり前じゃん」と切り捨てようと思えば切り捨てられる項目もあるのですが、その部分に再度注目することで意識が高まるので良かったです。
    「当たり前」の中にこそ真理はあり、「当たり前」は決して外す事はできず、そして「当たり前」の事を「当たり前」にやるのがどれだけ難しい事かを再認識する良い機会になったと思います。

    この本はリファレンス本ではないのですが、コンテンツを制作する上で迷った時にはたま~に目次に目を通して参考にできそうです。

    あまり遠くの人には貸せませんが、社内であれば誰でもお貸ししますので、興味があれば一言かけて貰えればと思います。

    次は何読もうかなぁ~。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/09/132012/11/13

    カテゴリー 技術 / デザイン / 制作
  • レスポンシブウェブデザインについて思ふ

    WEB大好き竹内です。こんにちは。
    生活の殆どがWEBと繋がっています。

    レスポンシブウェブデザイン。流行っていますね。
    実際の導入以上に言葉がバズワード化して一人歩きするのはこの業界ではよくあることですが、これもまたそのひとつと感じています。
    レスポンシブウェブデザインの定義がはっきりしないまま「PCとスマホで同じコードで見られること」とか「PCとスマホでレイアウトが変わる」とか「画面サイズを変更するとレイアウトが変わる」など漠然とした意味でこの言葉を使っている人も多い気がします。

    別に言葉遊びがしたい訳ではないので「レスポンシブウェブデザイン」がどうということでもないですし、レスポンシブウェブデザインの意味について問いただそうという訳でもないです。
    ただ、流行言葉になってしまったこの概念が少し寂しいなと感じています。

    と言うのも、
    レスポンシブウェブデザインの様な「多種のデバイスで適切なアウトプット」という概念は、もっともっと昔から存在して、その頃はまだスマートフォンやらタブレットやらが存在していた訳ではないので、あまり目立った主張や華やかな世界ではなかったのも事実なのですが、その当時でも「テキストブラウザ」や「音声ブラウザ」の様なブラウザ、いわゆるPDAと呼ばれる様なデバイスなどは存在していて、それらの利用者に対しても問題なく情報が伝えられるというのが標準化(ではないかもしれませんが)などの理念に含まれていた様に思っています。

    それが今やHTML5だ、JavaScriptを用いたリッチインターフェイスだ、レスポンシブウェブデザインだ、モバイルファーストだと叫ばれ始め、旧デバイス利用者はどの様にWEBを利用出来ているのかを想像すると心が痛みます。

    僕自身、WEBは弱者の為にこそあるべきだという想いが強いので、
    このままWEBが先端者(?)だけのものになって行かなければいいなと思っています。
    そこにかける優しさがあるのであればこっちにも。。。そんな風に思いながらレスポンシブウェブデザインという言葉を眺めるそんな夏の終わりでした。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/08/292012/11/13

    カテゴリー 技術 / デザイン / 制作
  • ApacheとnginXを比較してみた感想

    最近家庭の事情により留守番が多く、色々なパフォーマンスの比較に凝っています。
    言語間の処理(演算)スピードの比較、ボトルネックになりやすい
    データベース周りの比較などなど
    文献を読むだけでは知能レベル的にしっくり来ず理解できないため…
    実際に比較して勉強しています。

    今回はその中からWebサーバーの比較結果について書いてみます。
    2011年頃から一気にシェア率を伸ばし、シェア率第2位「IIS」の
    すぐ背後に迫る勢いのシェア率第3位「nginx」と不動の第1位「Apache」を比較してみました。
    Azureが順調なのかMS IISも2012年頃から復調の兆し(逆にApacheのシェア率は縮小)
    があるため、今後のシェア率の動向には要注目です。
    http://news.netcraft.com/archives/2012/07/03/july-2012-web-server-survey.html
    (nginxのシェア率10%越えてるんですね!!)

    比較はベンチマークの定番簡易ツールであるabコマンド(Apache Bench)を利用しました。
    基本オプションは以下になります。
    -c 同時に発行するリクエスト数
    -n リクエスト発行総数
    -t 負荷テストの実行時間

    検証方法としては、-n(総リクエスト数)を指定してどれだけの”応答時間”で捌けたのかを
    検証する方法や、-t(負荷テストの実行時間)を指定して、どれだけの”リクエスト数”を捌けたのか
    を検証する方法がありますが、今回は-nを指定して、所定のリクエスト数に対してどれだけの
    応答時間で捌けているのかを検証してみます。(総処理時間やスループットを比較)

    ******************************************************************************************
    ※例
    ab -c 10 -n 100 “http://localhost/”
    この場合、http://localhost/ に対して、同時発行(接続)リクエスト数が10、
    合計100リクエストを投げることになります。(同時に10個ずつのリクエストを合計10回実施)

    abコマンドの結果は以下になります。
    Server Software: nginx/1.3.4
    Server Hostname: comparehost
    Server Port: 8000

    Document Path: /
    Document Length: 43279 bytes => レスポンスデータサイズ(アクセス先ファイルサイズ)

    Concurrency Level: 10 => 同時接続数
    Time taken for tests: 6.005 seconds => 全ての処理が完了するまでの総時間
    Complete requests: 100 => 成功したリクエスト数
    Failed requests: 0 => 失敗したリクエスト数
    Write errors: 0
    Total transferred: 4383881 bytes
    HTML transferred: 4360146 bytes
    Requests per second: 16.65 [#/sec] (mean) => 1秒あたりの平均処理リクエスト数(スループット)
    Time per request: 600.516 [ms] (mean) => 1同時リクエストあたりの平均所要時間
    Time per request: 60.052 [ms] (mean, across all concurrent requests) => 1リクエストあたりの平均所要時間
    Transfer rate: 712.91 [Kbytes/sec] received => 1秒あたりの受信容量(byte数)
    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 28 552 244.4 576 2030
    Processing: 0 29 68.9 5 464
    Waiting: 0 2 7.7 0 34
    Total: 220 581 208.7 584 2030

    Percentage of the requests served within a certain time (ms) => 処理時間毎の割合
    50% 584 => 左記の場合、50%のリクエストが584ms以内に処理されたことを表す
    66% 605
    75% 623
    80% 635
    90% 702
    95% 879
    98% 1050
    99% 2030
    100% 2030 (longest request)

    ******************************************************************************************

    検証前に、環境の確認です。
    ○abリクエスト元ホストは同一マシン(自サーバーからではなく別ホストからのリクエストのため
    ○検証環境(リクエスト先サーバー)は同一マシン
    ○レスポンスデータサイズ(Document Length)は同じ ※nginx贔屓でリクエスト内容は静的コンテンツ…
    ○ApacheのMPMはprefork
    ○ApacheのVerは2.2.3(2.4.3ではないです。。)

    準備ができたので検証してみます。
    まずは同時接続数1で100回リクエストしてみます。
    ◆Apache(ab -c 1 -n 100 “http://comparehost/”)
    Server Software: Apache/2.2.3
    Server Hostname: comparehost
    Server Port: 80

    Document Path: /
    Document Length: 43279 bytes

    Concurrency Level: 1
    Time taken for tests: 12.173 seconds
    Complete requests: 100
    Failed requests: 0
    Write errors: 0
    Total transferred: 4355000 bytes
    HTML transferred: 4327900 bytes
    Requests per second: 8.22 [#/sec] (mean)
    Time per request: 121.727 [ms] (mean)
    Time per request: 121.727 [ms] (mean, across all concurrent requests)
    Transfer rate: 349.38 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 98 121 19.1 119 220
    Processing: 0 0 0.4 0 3
    Waiting: 0 0 0.0 0 0
    Total: 98 122 19.1 119 220

    Percentage of the requests served within a certain time (ms)
    50% 119
    66% 123
    75% 128
    80% 130
    90% 145
    95% 157
    98% 198
    99% 220
    100% 220 (longest request)

    ◆nginx(ab -c 1 -n 100 “http://comparehost:8000/”)
    Server Software: nginx/1.3.4
    Server Hostname: comparehost
    Server Port: 8000

    Document Path: /
    Document Length: 43279 bytes

    Concurrency Level: 1
    Time taken for tests: 13.142 seconds
    Complete requests: 100
    Failed requests: 0
    Write errors: 0
    Total transferred: 4351400 bytes
    HTML transferred: 4327900 bytes
    Requests per second: 7.61 [#/sec] (mean)
    Time per request: 131.420 [ms] (mean)
    Time per request: 131.420 [ms] (mean, across all concurrent requests)
    Transfer rate: 323.35 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 97 130 27.4 123 330
    Processing: 0 2 1.4 2 10
    Waiting: 0 0 0.0 0 0
    Total: 99 131 27.3 124 330

    Percentage of the requests served within a certain time (ms)
    50% 124
    66% 127
    75% 133
    80% 137
    90% 158
    95% 187
    98% 194
    99% 330
    100% 330 (longest request)

    接戦です。
    総処理時間はApache、スループットはnginxが競り勝ちました。
    nginxの方がスループットが勝っているため、マルチ処理が得意なnginxが
    総処理時間でも勝りそうな気もしますが、総リクエスト数が少ない&受信容量が勝った分なのか、
    総処理時間はApacheに軍配が上がりました。
    ただし、どんぐりの背比べでもあり、同時接続数も1のためあまり参考にはならない結果です。

    ******************************************************************************************

    次は一気に同時接続数を増やし、同時接続数50で1000回リクエストしてみます。
    ◆Apache(ab -c 50 -n 1000 “http://comparehost/”)
    Time taken for tests: 62.630 seconds
    Requests per second: 15.97 [#/sec] (mean)

    ◆nginx(ab -c 50 -n 1000 “http://comparehost:8000/”)
    Time taken for tests: 63.534 seconds
    Requests per second: 15.74 [#/sec] (mean)

    一気に同時接続数&リクエスト数を増やしましたが、これもほとんど変わらない結果でした。
    リクエスト数を10000回まで増やしても大きな差は発生しなかったため、
    同時接続数50、且つリクエスト数10000程度であればApache、nginxで特に大きな差はなく捌けるようです。

    ******************************************************************************************

    それではということで、次はリクエスト数を固定(1000回)し、
    同時接続数を増やしていきながら処理結果を観察してみました。
    ※ここからリクエスト元を自サーバーからに変更してます。

    ◆Apache
    =>同時接続数100(ab -c 100 -n 1000 “http://comparehost/”)
    総処理時間 :0.229897 seconds
    スループット:4349.77 [#/sec] (mean)

    =>同時接続数200(ab -c 200 -n 1000 “http://comparehost/”)
    総処理時間 :0.266142 seconds
    スループット:3757.39 [#/sec] (mean)

    =>同時接続数300(ab -c 300 -n 1000 “http://comparehost/”)
    総処理時間 :0.794779 seconds
    スループット:1258.21 [#/sec] (mean)

    =>同時接続数400(ab -c 400 -n 1000 “http://comparehost/”)
    総処理時間 :7.133020 seconds
    スループット:140.19 [#/sec] (mean)

    =>同時接続数500(ab -c 500 -n 1000 “http://comparehost/”)
    総処理時間 :14.90692 seconds
    スループット:70.97 [#/sec] (mean)

    同時接続数が300以上から明らかに性能が落ちています。
    MaxClientsを256に設定しているため、許容範囲を超え捌ききれなくなっているためだと考えられます。
    (因みに、MaxRequestsPerChildは200にしている)
    nginxはどうでしょうか!?

    ◆nginx
    =>同時接続数100(ab -c 100 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.94022 seconds
    スループット:10635.81 [#/sec] (mean)

    =>同時接続数200(ab -c 200 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.180318 seconds
    スループット:5545.76 [#/sec] (mean)

    =>同時接続数300(ab -c 300 -n 1000 “http://localhost:8000/”)
    総処理時間 :2.794196 seconds
    スループット:357.88 [#/sec] (mean)

    =>同時接続数400(ab -c 400 -n 1000 “http://localhost:8000/”)
    総処理時間 :1.264635 seconds
    スループット:790.74 [#/sec] (mean)

    =>同時接続数500(ab -c 500 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.100467 seconds
    スループット:9953.52 [#/sec] (mean)

    ん?んん??
    Apacheよりスループットは高いけど、やっぱり同時接続数が増えるのと合わせて
    性能は落ちるな。。。と思いきや、同時接続数が500になったタイミングで一気に
    スループットが上がっています!

    =>同時接続数600(ab -c 600 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.85274 seconds
    スループット:11726.90 [#/sec] (mean)

    =>同時接続数700(ab -c 700 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.592253 seconds
    スループット:1688.47 [#/sec] (mean)

    600でも引き続き高いままで、700になり再度下降し始めました。
    nginxの場合は同時接続数が少なすぎると性能が落ちるのか、特性を活かしきれないようです。
    いずれにせよ、Apacheと比較すると圧倒的に静的ページへの同時アクセスを捌く能力は高いようです。

    【比較結果の個人的な感想】
    ○負荷が高くなく、早期セットアップが必要な場合は「Apache」
    ○負荷が高く、スケーラビリティが要求される場合は「nginx」
    ○静的ページに同時多数のアクセスが想定される場合は「nginx」
    ※動的ページは処理内容やサーバスペックによるため現状では判断できない(要調査)
    ○ある程度の同時アクセスが見込めない場合は「Apache」
    ○同時アクセス数は小さく、単純にリクエスト数が多い場合は「Apache」

    Apacheも2.4.x以降に大きく性能改善がされ、同時アクセス時の処理耐性はnginxよりも
    優れいているという情報もあるため、静的ページにおいてもチューニング次第ではnginxより
    優れたパフォーマンスを得られる可能性もあります。
    と、結局のところ確信にせまる特性を掴みきれてはいない状態ですが、、、
    少しだけnginxの特性を理解できたと思います。(動的ページの比較検証はできてないけど。。。)

    動的ページの検証はさておき、次回はデータベース周り、
    特にNoSQL(Redis、HBase、Cassandraなど)関係のプロダクトについて比較検討してみようと思います。
    噂のRedisの爆速っぷりを体感しようと思います。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    伊藤 康平投稿者 伊藤 康平

    投稿日: 2012/08/272012/11/13

    カテゴリー 技術 / デザイン / 制作
  • TLFTextFieldのバグ

    お疲れ様です。守谷です。
    技術系のナレッジを書く場所を忘れてしまったのでスタッフブログに書いてしまいます。

    FLASHの新しいTextFieldクラスとしてTLFTextFieldなるクラスができました。
    何が違うのかっていうと、いままで使っていたTextFieldより細かい設定ができます。
    設定内容については割愛しますが、TextFieldよりはるかに便利になりました。
    ですが、それゆえバグも多いようです。何点か紹介します。

    ・wordwrapをtrueにして、「text = “hoge”」と代入するとwordwrapが効かなくなる
    TLFTextFieldではtextに直接代入するのは推奨していないようです。なぜかはわかりません。
    対策方法としては、appendTextとreplaceTextを使用すると防げます。

    ・INPUTモードのときにtextalignをleft以外にするとINPUTクリック範囲がずれる
    こちらのバグは対処方が見つかりませんでした。
    Adobeのフォームで探しても「バグですねー」で終わってしまっています。。。
    対処方をご存じの方、Vitalifyの守谷までご連絡ください!!

    TLFTextFieldはググっても情報がほとんど出てこないので、世間ではあまり流行ってないようです。
    先日FLASHプレイヤーの最新バージョンが公開されましたが細かいバグFIXも行ってほしいものです。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/08/242012/11/13

    カテゴリー 技術 / デザイン / 制作
  • Rubyに手を出しました

    PM部の里山です。

    最近、とあるきっかけによりRubyの勉強を始めました。

    もともと業務系のCOBOLer出身なので、
    JavaやPHPみたいなWeb系の開発には精通していなかったのですが、
    せっかくだから少し斜め上を行ってRubyでも覚えようと思い参考書を買いました。

    触りの数10ページしか読んでいませんが、
    恐ろしく簡単でビックリしたというのが第1印象です。

    基礎的な予約語を使って簡単なメソッドを一つ入れたお勉強プログラム程度なら、
    本当に猿でも書けそうです。

    まだ単純なコードが中心なので後々ハマる部分は出てくると思いますが、
    この解り易さは日本人が設計したお陰かもしれません。

    環境だけ作ったらちょこちょことコマンドラインのプログラムを作って、
    慣れたらRailsなんかにも手を出してみようかと思います。

    オススメかと聞かれると、
    そこは時代の流行なんかにも左右されるので解りませんが、
    プログラミングの入門言語としては最適な気がします。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    里山 智秋投稿者 里山 智秋

    投稿日: 2012/08/092020/11/05

    カテゴリー 技術 / デザイン / 制作
  • LL Decade に参加してきました。

    お疲れ様です。横井です。

    先日の土曜日(8/4)に”LL Decade”というイベントに参加してきました。

    LLとは、Lightweight Languageの略で、一般的にはPerl、PHP、Ruby、Python、Javascript辺りのスクリプト言語の総称になります。
    こちらのイベントは、LLに関しての最新の情報を、その道に精通している方々からお話が聞けるという内容になります。
    また、今年で10周年になりまして、書籍で名前を聞いたことがあるような方々のお話しが聞けるとあって、今回参加してきました。

    前半の”基調講演”や”Language Update Decade”の辺りは、最近の各スクリプト言語の動向を聞くことができて、大変良かったです。
    (Rubyが来年20周年になるのに合わせて、バージョン2.0を出すなどといったお話しなどが聞けたりしました。)

    昼食後の後半は、”プログラミング言語処理系を自作してわかったこと” や ”俺たちの継続的hogehogeは始まったばかりだ!”の辺りは、私には内容がちょっと難しく、お腹がみたされ、クーラーの効いた環境で聞くには、少し大変でした。

    ”Lightning Talks”は、私がよく参考にさせていただいているサイトの管理者の方々の発表となりまして、内容も身近なところでしたので、大変おもしろかったです。

    こちらのイベントは有料になりますが、内容は大変良かったので、来年も参加したいと思っています。

    以上です。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/08/082024/04/26

    カテゴリー 技術 / デザイン / 制作

投稿ナビゲーション

前のページ ページ 1 … ページ 43 ページ 44 ページ 45 … ページ 48 次のページ