Quantcast
Channel: SHANON　Engineer's　Blog
Viewing all 210 articles
Browse latest View live
↧

しゃのんあどべんとかれんだー 20 日目 (JavaScript Web Speech API を試してみました。Speech Recognition API 編)

December 31, 2015, 6:59 am
$
0
0
↧
Search

しゃのんあどべんとかれんだー 21 日目 (JavaScript Web Speech API を試してみました。Speech Synthesis API 編)

December 31, 2015, 6:59 am
$
0
0
↧
↧

しゃのんあどべんとかれんだー 23 日目 (Docker であそぼう！)

December 31, 2015, 7:00 am
$
0
0
↧

しゃのんあどべんとかれんだー 24 日目 (Docker で Perl 5 を動かしてみました)

December 31, 2015, 7:34 am
$
0
0
↧

しゃのんあどべんとかれんだー 22 日目 (vegeta 様が負荷テストを行ってくれる？)

December 31, 2015, 8:25 am
$
0
0
↧
↧

しゃのんあどべんとかれんだー 25 日目 (PostgreSQL の now() の罠(?))

December 31, 2015, 9:12 am
$
0
0
↧

移転のグルメ(芝・三田・田町ランチ編)

February 2, 2016, 5:12 pm
$
0
0
2月1日に株式会社シャノンは新オフィスでの業務を開始しました。そして社内インフラ担当の私 masuda も当然のように移転業務に関わりましたので、その業務中に得た知見などをいくつかブログネタにしたいと思いますが、まずは(技術ブログらしくない)軽いネタから。

新オフィスへの移転というといくつか気になるところがあると思います。交通の便・新オフィスの使い心地・オフィスの周りの環境などが上がろうかと思いますが、自分が一番気になる点は圧倒的に

「ランチ(昼飯）の選択肢の充実具合」

です(断言)。

今までのオフィスが虎ノ門で西新橋エリアに近接しており、ランチ事情はかなり恵まれていたので今回の移転に際して(個人的に)かなり心配したのですが、慶應仲通り商店街を中心として充実していることが分かりほっとしているところです。

以下は主に2015年12月～2016年1月の間に、移転工事の進捗確認立会等のついでにランチを求めて「孤独のグルメ」モードで自分の脚と勘を頼りに探して入ってみたお店をまとめてみた次第です。

また弊社だけではなくて、他の会社勤務の方でも港区芝・三田・田町エリアに最近オフィス移転してきた方もいらっしゃることでしょうから、参考になれば幸いです。

なおこのリストは個々のお店について私masuda が何かを推奨する目的ではないことおよびお店の情報等について内容等を保証するものではない申し添えます。



移転のグルメ(芝・三田・田町ランチ編)List

<順不同>

・浪花屋





(食べたメニュー) レバニラ炒め定食 790円(多分)

・ホルモンまさる

(食べたメニュー) モツ煮込み定食 780円



・フニクリ フニクラ













(食べたメニュー) ランチピザ　1000円　(多分)



・龍門













(食べたメニュー) マーボー丼＋餃子 880円(多分) 


・日膳坊













(食べたメニュー) レバニラ炒め定食 850円

・ベンダーキッチン 三田店

(食べたメニュー) 特製チキンカレー　600円(多分)

・欧風料理屋ビストラ

(食べたメニュー) パスタランチ 900円

・LICOT













(食べたメニュー) パスタランチ 900円

・つるの屋




(食べたメニュー) 豚ロース　黄金揚げ定食　700円

・むらさき山













http://tabelog.com/tokyo/A1314/A131402/13046911/
(食べたメニュー) 中華そば　750円


・ライムズインディア












http://tabelog.com/tokyo/A1314/A131402/13034684/
(食べたメニュー) 豆のカレー(ダール)　(多分)900円

・Taka's Kitchen



(食べたメニュー) ガパオライス 950円


まとめ？


技術的に新しいことにチャレンジするのも新しいお店を開拓するのも同じような｢勇気｣が必要なんだと思っています。安易な定番に逃げずにそのような勇気を失わずに行きたいものだと思っています。

シャノンでは、一緒にランチを開拓しつつ技術面も切磋琢磨できるメンバーを募集中です。
http://www.green-japan.com/job/29900

新しいオフィスで一緒にランチと技術を開拓しましょう。


↧

「思いつき」から始めるデータ分析〜技術ブログ編〜

February 4, 2016, 6:10 pm
$
0
0
こんにちわ。ishikawaです。
みなさん、データ分析してますか〜？


データ分析というと、
「難しそう」
「専門的な知識が必要なため、学校に通わないとできない」
「少なくとも数年は業務経験を積まないといけない」
というイメージがあると思います。

私もデータ分析を実際にやってみるまではそう思っていましたが、「思いつき」からデータ分析を始めてみると、かなり敷居低く始められることがわかりました。

データ分析のはじめの一歩、例えば、仕事で企画・提案をするためにある程度根拠のある資料を提出しなければならないときなど、試しにこれから説明する手順で実際にやってみて、雰囲気をつかんでみるのもいいかもしれません。

最初から完璧にやることを目指すと、結局何もできずに終わってしまったなんて経験あるかと思います。はじめから100パーセントを目指すのではなく、自分のできることから始めるのがいいのではないでしょうか。

そう、スターウォーズシリーズに登場するのヨーダのあの名言、
「No! Try not. Do. Or do not.」
で、今からデータ分析始めてみましょう。


経緯

弊社では、昨年度からその年に投稿されたブログのPV数のランキング上位５名はタダでお寿司が食べられることになっています。以下がランキングです。

＜2015年シャノン技術ブログランキング＞
  1. Google のバグ予測アルゴリズムとbugspotsの導入
    tsucchi 3995PV
  2. そんな自動化で大丈夫？『システム自動化標準ガイド』で自動テストを点検しよう！
    chappie 3085PV
  3. 小さな会社がScalaでマイクロサービスを始めて良かった3つのこと
    ishikawa 3073PV
  4. ドキュメントのレガシー化、忘れていませんか？APIマニュアルWEB化までの経緯
    kzhirata 2840PV
  5. bugspotsを3か月くらい運用してみた話
    tsucchi 1710PV
昨年度はお寿司制度を導入したこともあり、今まで以上に投稿数が多い年でした。しかし、ランキングをみていると、なんとなく全体的に例年よりPV数が落ち込んでいるのではないかという気がしました。

ブログは「採用」目的も兼ねているので、PV数が落ち込むと、採用にくる母集団の減少につながりかねません。また、技術会社としてブログを読んでくれている方に価値あるものを提供できているのかという疑問にもつながります。

ただ、「PV数の減少」は個人的な感覚でしかなく、何か根拠があるものではありませんでした。何も数字やデータをださないまま、改善はできないので、実際にブログデータを分析してみることにしました。


1.「思いつき」から始めてみよう

以前の私はデータ分析について
  • とにかくデータを集める
  • とりあえずグラフ化してみる
  • ひたすら分析手法の知識を深める
という考えでした。

もちろんこれらの習得は必要ですし、大切なことだとは思うのですが、初心者の私にとってはとてもハードルの高いもので、何年かかったら分析を始められるのかわかりません。また、これまでの経験として膨大なデータを前に途方にくれ、とりあえずグラフにしてみて満足して、当初の目的がなんだったか忘れることも多くありました。そんな状況の中、出会ったのが「仮説アプローチ」というものです。

「仮説アプローチ」について

参考にした「それ、根拠あるの？と言わせないデータ・統計分析ができる本」という本の中に「仮説アプローチ」、つまり最終的な目的をはっきりさせ、目的に沿った仮説をデータを使って客観的に確認（検証）していく方法が書かれていました。

何か問題が起こった時に、私たちは「どこに問題があるのか？」考え、いくつか思い当たる原因について考えます。その考えた内容は「仮説」であり、「思いつき」でもあるため、妥当性を確認する必要があります。仮説をたてて、その仮説が本当に正しいのかどうかを様々なデータやロジックを使って確認する手法、それが「仮説アプローチ」です。

※仮説を立てることは、無駄な分析を避けることができ、目的が明確になり、複数の仮説に対する分析結果を組み合わせることにより、説得力のある答えを引き出すことにつながるといった良い点があります。
ただし、見えない課題を見逃すリスクや仮説を考えた人の思い込みやバイアスに左右されるといったリスクもあるため、注意が必要になります。

「目的」→「仮説」→「手段」を図式化

以下は、今回のデータ分析の目的と仮説、そして、手段を図にしたものです。


2. データ分析してみよう

では早速、データを使って仮説を検証してみましょう

仮説①：そもそもPV数減っていないのでは？

下記は年ごとのPV数をグラフ化したものです。


私たちはたくさんの数値が並んだデータを前にした時、まずは全体の合計値求めて、それから平均値を割り出し比較したりしますが、それだけでは不十分です。平均からはデータの「バラツキ」具合が見えないからです。そのバラツキを表現するのに便利なのが上記の箱ヒゲ図になります。

表には「四分位数」といった聞きなれない言葉があるかと思いますが、これは簡単に言うと、データを小さい順から並べて４等分にした境界にある値です。第1四分位数は1/4、第3四分位数は3/4の位置にあたる数値です。

ブログをはじめた2011年、2012年に比べて、箱の位置が低くまた、高さがありません。ブログを投稿してからの経過年数の違いがあるといえ、PV数が全体的に低く、バラツキもほとんどないことがこの図からわかります。

仮説②：技術ブログのライバルが増えた

下記はこちらのWEB各社の技術ブログのサイトの総はてブ数ランキングを出している記
事を参考にし、同じ手順で、2016年２月５日現在の技術ブログランキングと弊社の順位について、調べてみたものです。また手作業でブログが開設された年度を確認し追記しています。

※ランキングにある技術ブログは上記の記事をもとに作成してあります。すべてのWEB各社の技術ブログが記載されているというわけはないのでご注意願います。

会社名ブログ開始年度はてブ数
1クラスメソッドDevelopers.IO2011134930
2クックパッドクックパッド開発者ブログ200856042
3paizapaiza開発日誌201340194
4アシアルアシアルブログ200640136
5ヤフーYahoo! JAPAN Tech Blog200835330
6ミクシィmixi Engineers' Blog200726294
7グリーGREE Engineers' Blog201025587
8カヤックtech.kayac.com200823146
9KLabDSAS開発者の部屋200620667
10はてなHatena Developer Blog201019692
11nanapinanapi TechBlog201316638
12さくらインターネットさくらのナレッジ201314277
13サイバーエージェントサイバーエージェント 公式エンジニアブログ201012596
14インフィニットループインフィニットループ技術ブログ201111930
15Livedoorlivedoor Techブログ200610513
16ハートビーツインフラエンジニアway20099259
17DMMツチノコブログ20139045
18pixivpixiv engineering blog20147492
19サイボウズCybozu Inside Out20097440
20アイレットcloudpackブログ20106655
21QiitaQiita Blog20116077
22サーバーワークスサーバーワークス エンジニアブログ20095981
23シャノンシャノン技術ブログ20115606
ランキング上位にあるブログの開始年度は弊社よりも古いものが多く、ここ数年で技術ブログのライバルが増えたわけではなさそうです。

仮説③：ある特定ユーザの拡散がなくなった

下記はGoogleAnalyticsによる投稿記事の流入元のデータになります。


流入元の大半がキーワードによる検索（＝xxxxx/organic）となっており、SNS等のシェアされたURLからの流入は少ないことが見て取れます。上記からフォロワー数の多いユーザの拡散がなくなったからというわけではないことがわかります。

仮説④：投稿者の偏り、投稿内容の偏り

本当は、投稿内容をカテゴリごとに分けて、カテゴリとPV数の相関を調べたかったのですが、記事によっては多岐にわたる内容のものもあり、カテゴリに分ける作業はとても難しく断念しました。

そのため、まずは年ごとの投稿者数（投稿者の重複を省いたもの）とPV数の相関をグラフにしてみましたが、実際のところ年ごとにまとめてしまうとデータ量が少なすぎるので、相関があるとは言えません。（ごめんないさい）
2015年は投稿数が今までで一番多い年でしたが、投稿者数は少ない年だったようです。


さらに、全体のブログランキング上位（10位まで）にはどんなものがあるか調べてみました。ランキング上位にきている記事は体系的な技術・知識、プロジェクトで得られた知見等の記事が多く、長い期間読まれているものが多いようです。
タイトル投稿者投稿日付PV数
115分で始めるmonitによるサーバ監視fujya.sh2011/11/2438004
2ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側）kiyoto.s2011/09/0634968
3Twitter Bootstrap＋その他で「本当に」イケてるモックを作る手順benzookapi2012/09/0425328
4Jenkins, Seleniumを使った自動テストの課題とこれからの取り組みinoue2011/11/0124285
5vim で実践！　コードリファクタリングkiyoto.s2011/03/1021615
6GitHub Enterpriseがやってきた！～導入編～松井信也2013/11/1313981
7tarコマンドを負荷制御（bwlimit指定）して実行する方法fujya.sh2012/08/1413636
8数百GBのPostgreSQLを一瞬でバックアップする方法Yanagisawa2011/10/1711620
9Sublime Text 2 で Play2 Scala しようikeike4432012/07/1810575
10アンドロイドアプリを作ってみよう　～開発環境準備（その１）～kashiwagi2011/04/209233


まとめ

ブログを始めた当初よりもPV数が落ちていることは実証できましたが、減少につながっている要因の追求までには至りませんでした。そのあたりはやはり分析能力、経験、数値センスが影響しており、学習不足を痛感しました。

しかし、仮説をもとに分析すすめていくと複数の視点から論理的に掘り下げていくことができ、見えてきたものも多いので、これで終わりにするのではなく、この先も試行錯誤を行い、ブログ改善につなげていけたらと思います。
（この分析をもとに、いくつか具体的な改善作業も行うことになっています）

    最後に

    文章は読み手の想像力を刺激し、行動を起こさせる発火剤のような性質を持っているものだと思います。弊社でも面接の際に技術ブログをみて、採用に応募したと言ってくれる方がかなり多くいます。

    PV数PV数とうるさく言ってきましたが、もちろんPV数がすべてではありません。PV数が高いブログが読んだ相手の心を動かすブログではないとも思っています。
    読んだ人の心を動かすブログがどんなものなのか、ブログの運営を通じてこれからも学び、考えていきたいです。


    追伸

    データ分析を始めてみると、データの収集・グラフ化するのにかなりの時間と労力を使いました。（本ブログで利用しているBloggerサービスは、投稿ごとのPV数をとるAPIがないため、今回分析するのに、同僚の力を借りて、管理画面をcasperJSを使ってスクレイピングしてデータを取得しました。また、データビジュアライズするのにデータ整形および、集計をJavascript+αでゴリゴリ書いて行っています。）

    弊社のマーケティングオートメーションツールである「SHANON MARKETING PLATFORM」は昨年度より、Tableau社と連携したマーケティングデータの可視化、分析のサービスを提供しています。
    ご興味がある方はぜひ弊社までお問い合わせください。
    ↧
    Search

    フレッツの小型ONU を導入してみた

    February 23, 2016, 7:57 pm
    $
    0
    0
    masuda です。

    オフィス移転というとITインフラ的には回線サービスの見直しの機会(チャンス)ということになります。
    もちろん利用アプリケーションや既存の利用機器と(一番大事な)予算の関係もありなんでも導入できるわけではありませんが、今回はNTT東日本のフレッツを1回線引き込むことは決定していたので「小型ONU」を試してみました。

    小型ONUとは

    以下の写真のようにネットワーク機器のSFP+ インターフェイスに直接に刺さるONUです。

    小型ONU
    小型ONUをSFPに挿した



    NTT東日本の対応機種ページでは対応機種は2機種のみ記載されています(2015年2月現在)。
    但し以下のような有志ベースの情報ではどうやら大抵のSFP インターフェイスであれば問題なくつながるような感触を得ていたので、移転場所のフレッツの申し込みを行う際に小型ONU を申し込んでみました。

    (2015年2月現在では動作確認機種が増えていますが、2014年の10月ごろは動作確認機種はそれほど多くは無かったことも一応書いておきます)。

    最初のハードル：申し込み

    諸般の事情でISP契約とのバンドル申込みはもともと出来なかったのもありますが、小型ONUという単語が普通に通用するか怪しいと踏んだこともあり、普通にNTT東日本様のWEBより申し込みを行いました。
    当然NTT東日本の開通担当から電話が掛かってくるわけですが「小型ONUを使いたい｣といっても
    当初は話が通じませんでした(2015年11月現在)。
    「貴社のWEBページに掲載されているんだから申し込みできないわけが無いよね？｣的に強気に推すことで何とか話が通じて小型ONUでの開通工事を手配してもらえました。

    開通工事：あっけなく

    普通のフレッツ回線の開通と同じで、光スプリッタからケーブル配線してSCケーブルを出すところまでは同じ。
    普通の黒いONUで試験して工事業者さんの責任範疇は終了。
    その後SCケーブルを刺した小型ONUを渡されて「試してみてください」といわれて試してみました。

    小型ONU接続で「フレッツ・スクエア」ページにアクセス

    あっさりつながりました。工事業者さんも小型ONU接続を見るのは初めての事例のようで、「スイッチにつなげてパケット見て良いですか？」ということで端末をつなげてパケットを眺めてもらって「フレッツのIPv6 のルーターアドバタイズきてますねー」という感じの開通工事でした。

    その後：接続を試してみた機械とか

    本当は手持ちのSFPインターフェイスを持つスイッチ複数機種で試してみたかったのですが、オフィス移転作業の合間でやっていたために、あまり多くの機種では試せませんでした。


    なお接続を試したのは上記2台のみで接続できなかった機種は無かったことも付け加えておきます。あっさりつながったので事前に準備していた複数機種を試す必要もなくなったという側面も正直あります。
    現在は、ISP接続とフレッツワイドの2セッションを常用して使用していますが、3週間以上連続稼動していますが特に問題なく動いてます。
    当初予定ではDell PowerConnect3224 ではない別のスイッチに小型ONUを収容するつもりだったのですが、納期が微妙に遅れてしまって本番稼動までに間に合わなかったので、次のメンテナンスのタイミングで試してみてみるつもりです(もしその機器でつながったらこのページに追記します）。
    この接続確認情報は参考情報であり正常動作を保障するものではなく無保証であること、およびNTTの提示する要求仕様を満たしていない可能性があるのでご留意ください。

    まとめ

    どんな機械でも繋がるわけではないのがネットワーク機器の世界ですが、新しいことは試してみないと技術的選択肢の幅が広がらないので、これからも機会を捉えて新しいことにチャレンジするようにしていきたいと思っています。

    シャノンでは、新しい技術にチャレンジするスピリットを持ったメンバーを募集中です。



    2016年2月に移転したばかりの新オフィスで応募をお待ちしています！

    ↧
    ↧

    バグを見つけないテストを目指す

    March 7, 2016, 3:09 am
    $
    0
    0
    こんにちは。
    inomata@qaです。

    最近はテストでいかにバグを見つけるかよりも、いかにバグを出さない開発プロセスにするかという事を考えています。私はバグを見つけることに喜びを感じるクレイジータイプのテストエンジニアではないです。どちらかといえばテストする時間に昼寝がしたいです。自動テストの改善とかやっておきたいです。

    今回は、バグを見つけないテストを目指すという話です。
    「何言ってんだコイツ」とお思いでしょうが、まあ最後まで見てやってください。

     

    まず前提として

    シャノンの開発チームはアジャイルプロセスのスクラムで開発を行っています。
    スクラムのチームは開発者とQAが同じチームに属し、仕様を考えるところからリリースの手順作成まで（リリース作業自体は別の担当者）を一緒に作業します。仕様の提案や決定は一緒に行いますが、実装は開発者、テストはQAという役割に分かれています。また、開発するのは主にSMP（webアプリケーション）です。
    これらを念頭において見ていただければと思います。

    バグを見つけないテストとは？

    バグを見つけないテストとは、開発時から品質を上げ、テスト時にはバグがないコードを相手にしようという試みです。テスト時にバグを検出しなければ、早く開発が終わり、それだけリリースが早くなります。これはもう、良い事しかありません。
    決して、薄めに薄めたカルピスのようなテストケースを作るということではありません！

    どうすれば・・？

    まず、シャノンの開発プロセスはざっくりと以下のようになっています。
    1. チームに要件（ユーザーストーリー）が降ってくる 
    2. 要件をもとにチームが仕様を考える 
    3. 開発者が機能開発する 
    4. QAがテストする
    スプリントという短い期間にれらのタスクが発生します（主に2～4）。という事で、この2の仕様を考えるタイミングでテストを設計してしまいます。大事なのはテスト観点だけはしっかり洗い出しておくことです。例えば、 
    1. 開発対象の機能性テスト
    2. ほかの機能との動作、使用性の整合性
    3. メモリ使用やレスポンスといったパフォーマンス
    4. 影響する既存機能
    5. ISO9126の品質特性
    などです。
    仕様の決定とテストの設計が終われば、開発者は実装に入ります。なので、このテスト設計の成果物を開発者に共有します。つまり、「オレ、ここテストするからバグとか出さないように作っておけよ」という事を先に言っておくわけです。
    テストは開発より後の工程になるので、つい”後出し”になってしまいがちですが、こうすれば先に開発者のほうでバグを入れないコードを開発できるという狙いです。

    シャノンの場合（？）、機能を新規開発するとその機能はしっかりできている反面、既存機能への影響が大きく出てきます。これは開発者がどうのという話ではなく、今まで重ねてきた負債が悪さをしているという結果になっています。
    一方、ユーザー目線だったり他の機能との整合性といった、システム全体を俯瞰する目線というのは、開発者よりQAのほうが得意な傾向にあります。
    この方法は、そのシステムを俯瞰し、品質を意識した目線を開発の方へ早く回してやるということです。

    最後に

    これは、開発者とQAが同じチームで情報を共有し合い、またリスペクトしあえる、アジャイルならではの手法と思っています。ちょっとプロセスの順番を工夫するだけでテスト時のバグ減り、リリースが少しでも早くなるのであればやらない手はないです。
    プロセスには正解など無く、いかに目的に向かって良い活動ができるかということを、自分たちで改善していく事が重要です。今回は、どうすれば少しでも早くリリースができるかという事を考える中での活動の一環でした。 

    それでは！
    ↧

    コンテナの中のコンテナ　～Docker inside containers～

    March 9, 2016, 5:09 am
    $
    0
    0
    インフラチームのfujyaです。今日は社内勉強会があったので、その内容を垂れ流そうと思いBlog POSTです。


    Docker inside containers from Kazuaki Fujikura


    要はOpenVZコンテナの中でDockerコンテナを動かしてしまえという内容です。
    おそらく成功しました。
    好きな人には大好きなネタでしょう。あえてEC2使ったのはネタ的に面白そうだからです。



    https://openvz.org/Docker_inside_CT

    だいたい１年ぐらい前にこのページを発見したのが始まりで、昨日やっと試したらあっさりいって拍子抜けな感じでした。


    https://openvz.org/Download/kernel/rhel6-testing/042stab105.4

    042stab105.4の中に[net: Track netfilter modules per net-namespace, v3 (PSBM-31451)]という更新が入っていたのが、おそらく決めてなのかなと。tunとbridgeデバイスに関しては結構前からできてた気がするので、2015年2月頃のリリースで条件が整ったんだと思います。
    これによりOpenVZコンテナ内でiptablesの管理ができるようになったので、Dockerコンテナとのネットワーク疎通が実現したのだと。




    今日から開発チームの開発環境（OpenVZコンテナ）でDocker使えるようになりました。みんな今よりはほんの少しだけ開発をEnjoyできるんじゃないでしょうか。
    なにせ昨日試したばかりなので、余り脳内が整理されてないですが、チョットずつ使っていってもっと面白い情報が発信できるようになったらアップデートしようかなと思っています。



    ※　ネットワークはbriegeを組み合わせて疎通させる




    とりあえずシャノンではコンテナ大好きな仲間を募集中です！
    https://www.green-japan.com/job/37651?lid=n_other_jobs







    「あなたが居るのは果たして現実世界？仮想世界？」
    ↧

    今やる価値のないコトを今やっている暇はないから、共感できる仲間と、死ぬまでの限られた時間でやりたいことを全力でやろうという話

    March 13, 2016, 6:32 pm
    $
    0
    0
    人はやがて死ぬ。

    ろうそくが燃え尽きるまでの間、何をするか、何ができるか、濃密に燃やすにはどうしたらよいか。
    技術者はモノを作る。モノを作るための技術を日々磨く。磨いた技術は何に使うのか。

    技術者はプロダクトを正しく作る。だが正しいだけでは誰も使わないモノが出来上がる可能性がある。

    だからプロダクトは、正しく作るだけでなく正しいモノを適正な品質で作る必要がある。
    そのためにはチームが必要だ。

    だから私たちはチームで開発をしている。
    一人で作るのではなく、チームでプロダクトを作っている。

    たとえば PM(プロダクトマネージャ)。
    PM は正しいモノにすることに責任がある。
    だから PM と二人三脚で進むことで、正しいモノを正しく作ることができるようになる。

    たとえば QA。
    QA は品質を保証することに責任がある。
    だから QA と二人三脚で進むことで、品質を保証されたモノを正しく作ることができるようになる。

    たとえばインフラ。
    いくらよいものを作っても一人しか使えなければビジネスにならない。たくさんの人に安定して使ってもらってはじめて価値が生まれる。

    何を作るのか。

    一生の間にいくつのプロダクトに関わることができるだろうか。何回新機能をリリースできるだろうか。何回デプロイできるだろうか。何回テストできるだろうか。何回ビルドできるだろうか。

    いずれも無限ではない。技術者として限られた回数のこれら貴重な経験を、どこで誰と行うか。それは技術を磨くのと同じくらい重要な判断だ。いま何をしているのか。それは今やる価値があるのか。今やる価値がないものをやる暇はない。

    たとえば負債返済。
    御多分に洩れず、プロダクトが成熟してくると「負債」と呼ばれる、手をつけがたい、厄介なコードが生まれてしまう。生き残ったプロダクトは無傷ではいられない。傷を癒し、機敏さを取り戻すことが必要だ。
    これは後ろ向きではなく、本質的な作業の一つだと思う。
    ヒトは生きるにつれ体の各所に問題を抱えるようになる。だからといって全てを捨て去ることは不可能だ。問題を抱擁しそのなかでいかにベストを尽くすか、濃密に生きていくためには考えないといけない。
    プロダクトも成長痛に始まり、各所に問題を抱えるようになる。だがそれをふまえて走り続けられるようにすることが、生き残るためには必要だ。正しく作るということは、この問題をいかに受け止めるのかということでもあると思う。ゼロから作ることとは別の、走りながら作り続けるという高度なエンジニアリングが求められている。

    繰り返すが我々はチームで開発している。
    そびえ立つ建物を一人で直せと言われても怯むだけだろう。同じ目標を共有できる多様な仲間がいてこそ向かっていける作業であり、よい仲間との作業だからこそ立ち向かう時間が有意義なものになる。

    たとえばマイクロサービス。
    大きな規模を管理可能に保つには分割統治が必要だ。マイクロサービスは一つの選択肢で、今まさにどのような形なら複雑さを管理可能なサイズにできるか議論している。今は大きな転換点にあると言ってもよいと思う。

    先を見据えた話。

    シャノンのプロダクトが提供している「マーケティング・オートメーション」は日本において今まさに立ち上がろうとしている状況で、日々新しい局面が生まれている刺激的な環境でもある。だから足元を整えることと、将来を捉えることを両輪でやっていく必要がある。すなわち新たな価値を提供していく必要がある。よりよい企画、さらなる生産性、あらたな技術スタックを追い求め、日々議論や勉強会を行っている。

    シャノンではそうしたカルチャーにマッチし、チームとしてともに走ってくれるあなたを待っています。

    PM

    QA エンジニア

    インフラエンジニア

    開発エンジニア

    この技術ブログは「技術部」が書いています。もちろん PM や QA やインフラも書いています。
    過去の記事を参照していただくことで、どんなメンバーなのかイメージが湧くことでしょう。
    私たちはいつでもあなたを待っています。共感した点をぜひ聞かせてください。




    ↧

    JaSST'16 Tokyo 参加してきましたレポート

    March 25, 2016, 7:24 am
    $
    0
    0
    こんにちは！
    inomata@QAです。

    去る3月8日に国内最大のソフトウェアテストシンポジウムのJaSST'16 Tokyoに行ってきました。
    今回もQAが総出で参加してきましたので、レポートをまとめたいと思います。

    ***********

    inomataレポート

    基調講演

    「Software Test Challenges in IoT devices  IoTデバイスにおけるソフトウェアテストの課題」

    IoTにおける課題とは、例えばwebサービスと組み込みのソフトウェアがつながるようになってきた。そうすると組み込みのソフトウェアwebの問題を、webサービスは組み込みの問題を意識しないといけなくなってきた。
    これらをテストしていくにはサービスとして包括的に捕らえる必要がある。手元の情報がいったいどこまで届くのかを意識しないといけない。

    IoTの課題を解決に導くアプローチ
    ・モデルベーステスト
    システムをモデル化をしてテストケースを導く。開発が作成するモデルとQAが作成するモデルの差分を取るとお互いの抜け漏れが見つけられる。また、UTPのようなツールを使うとよい。

    ・マスベーステスト
    テストに数学的アプローチを導入したもの。例えば、互換性テストのためのAndroid端末は、全部なんてとてもできないから、統計学的なアプローチを取る。ビッグデータや解析といった領域も数学的アプローチで対応。

    ・探索的テスト
    探索的テストはチャータがあるとやりやすいが、前述どおりwebと組み込みでは文化も観点も異なる反面、それぞれを意識しないといけないようになるので、それぞれの観点を持ち合わせる必要がある。

    ・標準ベース
    ISO29119、やIEEE1012-2012といった標準を用いる。このあたりの標準はIoTに向けて動きがあるみたい。

    そのほかIoT時代における課題
    ・大量データをどうするか？
    今後、扱うデータは増える一方。こいつを相手にするには
     - データを分類して効果的なデータ群を作る
     - あるいはデータではなくテスト結果を分析してテストを作る

    ・セキュリティ・プライバシーどうする？
    個人情報はどこからどこまで存在するのか？昨今騒がれる反面扱いが拡大している。

    ・互換性とか大丈夫？
    例えばスマートフォンをもってエレベーターに載ったとき、その電波が切れるとする。するとその先のシステムでデータが落ちて何らかのエラーになる。といった話は十分考えられる。
    ユーザーはヒトだけではなく、接続先のシステムでもある。

    所感
    IoTは領域が広がりすぎるから、いかに責任範囲を明確にして自分の領域の品質を担保していくかということと、エラーが発生したときにいかに安全に動作するかの作りこみをしていくかが重要になりそうです。
    今後リスクベーステストがはやりそうです。

    B2)「Web.JaSST ～ウェブ開発のテストや戦略～」

    webアプリケーションのQAによるパネルディスカッション形式
    ぶっちゃけトークが繰り広げられました。意訳も含めてまとめておきます。
    公開できない情報は載せていません。(たぶん)

    Q1.web業界でテスト戦略って乏しくない？
    ・メーカーのウォーターフォールプロジェクトとかに比べればそんなにカッチリしたテスト戦略はない。というか、web業界は変化が早いのでじっくり戦略を練る事はやらず、臨機応変に対応する必要があるのでこの方があっている。
    ・とにかくスピード重視。ただしドキュメントを作らないと属人化しやすいのはデメリット。
    ・チケット駆動を大切にしている。プロジェクトに関わる人はチケット上でコミュニケーションをとり、担当のタスクを順にこなしていく。とにかくチケットで情報管理&共有
    ・膨大なテスト戦略はないが、それぞれが最適な活動をしているといった感覚。特にテスト戦略が無いからといって困っている様子はないみたい。

    Q2.テストベースが無い場合どうやってテストする？
    ・とにかく動作確認で期待結果を作っていく。この時点E2Eの自動テストまで作っておくと後で役に立つ。
    ・サービスとしての価値をテストする。仕様どおり動いても、それがユーザーに価値を届けないと意味が無いので。
    ・知ってる人に聞きまくる。例えば、その製品が何をしたいかは売ってるいる人が知っている。場合によっては退職した人にも話を聞いたり。
    ・探索的テストを実施する。社内に探索的テストの知見をまとめて活用している。

    Q3.リリース前に判断や意見を求められたときどうする？
    ・判断できる材料を集めてリスクを伝える。
    ・判明しているリスクをカスタマーサポートに伝えておく。こうしてプロダクトのリスクをサポートに寄せて強気にリリースできる。サポートチームとの情報共有は大事。
    ・判断ができない時点できっと十分なテストをしていない。なのでリリースはしない。問題を出してやって現実を突きつける。
    ・リリース後に問題が起きた時の対応を決めておく。
    ・QAはプロジェクトの流れを止めるのではなく、プロジェクトをコントロールできる立場にある。

    その他
    リリースのスピードは？
    ・どんどん早くなっている。競合も早いリリースをしてくるので、戦うにはスピードが必要。
    ・リリース速度に伴い、ロールバックの仕組みは必須。

    所感
    弊社は今リリースのスピードが結構問題なっているのでそのあたりを質問してみたのですが、各社毎週リリースしていたり、スプリント終了ごとにリリースしたりと、すごいスピードでリリースしているとの事。さすがです。
    テストのプロセスをどうこうという話より、開発プロセスの中のテストをどうするかという話が重要と感じました。

    ***********



    hanレポート

    A2) 事例発表「テストの計測」～テストを測る～ 

    A2-1 「レビュー目的･観点設定の効果と課題」


    ・同じ内容のテストケースを２つを用意してそれぞれレビューを行ったところ、記載内容がわかりやすく、明確できれいになっているテストケース方がレビューしやすく間違いを探しやすかった。
    ・急で行われるレビューはアドホック状態となりがち、レビューを依頼される側で内容を把握しておらず、誤記・不明な点には気づくが、レビューアによっては指摘内容がばらばら（何を見てやればいいのか判断する余裕がなく、各自のスキルに依存される）
    ・役割分担ができていないため、指摘内容が重複したり、レビュー漏れが発生したりする
    ・レビューアが準備できていない状態で行われるレビューは有効なレビューにならない
    ・レビューを依頼する内容を事前に共有することで、誰がどの部分をレビューするなどの役割が決まり、レビュー対象の背景なと把握する準備など、レビューの目的・観点抽出などもっと具体化される。そのため担当領域に絞られ、重複や漏れが減る
    ・つまり、同じテストケースのレビューであってもレビューアが内容を把握できる時間が事前に準備できていれば、同じ時間（工数）を使っても効果的なレビューが実施できる
    ・レビューアの立場によっては観点が異なってくる
    ・製品の特徴・レビュー環境などを考慮してレビュー実施方法を採用するのも大事
    ・目的に合わせて適切な観点が必要になってくる
    →例と挙げられたのが、amazonのようなWebサイトで‘使いやすい‘を実現したい場合にボタンをクリックしてレスポンスがすぐ帰ってきてユーザがイライラしない、サクサク動くのも該当しますよね？と言ったけど、それってパフォーマンスじゃないかと質問もあった。
    パフォーマンスとして見ないといけないけど、これはこれで使いやすさの観点になるのではないかと回答。。。どっち正しい、ただパフォーマンスだと期待するレスポンス時間があってそれをクリアできるかどうかの話となるかと。。。

    感想
    ・個人的にはテストケースを書く時にこの機能は何を実現するための作ったモノなのか、自分はそのために何を確認したいのかを明確で簡潔に書くように心かけていますが、いくら綺麗に書いたテストケースであっても、急なレビューを依頼するとレビューアは機能やテストの目的が何なのか把握することから始まるので、これは要改善だと思いましたが、なかなかそうにはいかないのが現実です。
    ・自分の経験則でレビューアの立場から見ると、目的と期待結果が明確じゃないテストケースは本当にわかり辛くて、やるべきのことを漏れなくやっているかが気になる。個人的に思うには相手に理解してもらえるテストケースになっていない場合にはケース漏れの可能性が高いと思いました。

    A2-2 「テスト設計スキルの計測と教育効果に関する実験と考察」

    ・テスト設計って広範囲の意味で使われているけど、
    　テストの対象と目的を明確にする→計画
    　テスト対象を細かく砕いで→分析
    　目的み合わせてテストケースを作成する→設計
    　テストケースのテストを行う→実行
    ・近年ソフトウェアテストの書籍は出ている、やセミナーな・勉強会などは行われていており、そういった知識は習得できるが、スキル習得できる方法がなかなかないのが現実
    ・現場で先輩達がやってきたのがそもまま受け継がれているのじゃないかな。。経験のみであって適切な教育などが行われていないか。。と思われる
    ・実践に近いのがいいんじゃないかなと。。WAKATEとゆう１泊２日のWorkshopを開催した
    ・経験やテストスキルは各自それぞれ、若手の人が多い？
    ・何も教えず、課題を出してテストケースを作成してもらい、テストフォーマットもそれぞれ
    ・こうすればこるなること、条件・手順・期待結果、書き方は各自の経験によったりもする
    ・何も教えないで１回目→レクチャーしてから２回目→参加者間で話し合い・レクチャーしてから３回目を行った
    ・効果が高かったのは経験３年以下の人達だった、どこでスキルをみに付けたか詳しくわからないけど、経験のある人達はあまり効果が出てなかった、経験があるほど自分のスタイルが確立されているからかな？全体で言うと効果はみんな出てはいる
    ・参加者のアンケート結果によると１泊２日のWorkshopで３年間の経験値の価値がある回答は一番多かった、
    ・今後もどのような教育をするとどのような効果が出るかをさらに分析して，テスト技術の向上に役に立てたい

    感想
    ・１泊２日で３年間の経験値を得られるのは凄いと思いました。
    ・本Workshopの結果だと経験３年あれば、そのあとはテストケースの作成スキルはあまり伸びないようですが、製品全体の品質を向上させる中でQAのテストケースを作成は一部の業務に過ぎないと思いました。

    ***********


    kzhirataレポート

    E4) ユーザビリティテスト ～UX（ユーザーエクスペリエンス）ってなんですの？～

    基本は単純:ユーザにてスクを提示して、その実行過程を横で観察するだけ。 思考発話:ユーザーに思ったことを口に出しながらタスクを実行してもらうこと。

    判定基準

    下記3つの観点で判断する。

    効果:ユーザがそのタスクを完了できるか
    効率:ユーザがなるべく遠回りせずにタスクを完了できるか
    満足度:ユーザがタスクを完了するまでに、不安や不満を感じないか（喜ばせることではない）
    ユーザーテストとは、ユーザーに製品をレビューしてもらうことではない。 ユーザーが意見を言ってはならない。

    昔

    ユーザビリティラボ
    4週間
    200万円
    専門家の報告書 こんなことまでしなくてよい。
    今

    「これで十分」ということを積み重ねていく。

    部屋の片隅で
    身近な道具で（Ziggiでスマホ操作を録画）
    手軽に分析（専門的な手法を駆使しなくてよい。）
    タスク

    各タスクを積み重ねてシナリオみたいにする。

    「○○してください。」
    「次に○○してください。」
    (例)カメラでスマホアプリのテストをとったとき

    指の動きをとりたい。
    なるべくリラックスした環境でテストしてもらう。
    ここから実演

    折込チラシアプリで、身近なスーパーの情報を見つけてもらう。

    ユーザーにインタビュー（どんな人なのか、アプリに関連する普段の週間をヒアリング）
    自分で使っているデバイスを使う
    タスクを提示
    操作ごとにつぶやいてもらう
    全体の感想をもらう（最後に☆の数を聞く、今後使うか）
    このテストについての感想をもらう（ユーザテストは初めてか？など）
    1人目：男子大学生 2人目：女子大学生

    検証

    インタビューが終わった後に、分析して、再度アプリを改善するサイクルを1回は実施すること

    質問

    カメラで録画したVTRを検証する方法は？自動化とかないのか？ → 力技でがんばるしかない。
    話してくれないユーザーがいた場合、どうすればいい？ → それで問題ない。下手にインタビュアーが話しすぎないようにする。
    どんな人に対して、テストを依頼すればいい → ターゲットとしているユーザー、今回のケースでは紙のちらしを見る人

    ***********

    今回もアツいセッションが各会場で繰り広げられていました。
    モチベーションがアガる良いイベントなので、行ったことの無い方はぜひ参加してみてください。テストの自動化や戦略の話題にも事欠かないので、テストエンジニアのみならず開発者やマネージャーの方も参考になると思います。

    それでは！
    ↧
    ↧

    リレーショナルデータベースの考案者 E.F.Codd の論文を読むための３つのポイント

    April 24, 2016, 7:14 pm
    $
    0
    0


    どうもこんにちは、開発のKomaDです。

    桜前線も本州をおおむね通過し、残すところは北海道くらい。こんな暖かい季節はなんだか初心に帰って勉強したいという思いが強くなりますよね。
    Webアプリケーションの業界でも、長年変わらない「基本」というとどんなものがあるだろうかと考えてみたところ、とにかく昔から使われて続けているデータベースの基本など良いのではと思いました。

    そこで今日は「基本」をとにかく突き詰めていくために、そもそものリレーショナルデータベース（RDB)の考案者であるE.F.Coddの論文を読んで勉強してみようと思います。

    この論文はCoddがRDBの構想を一般に発表した論文で、公開されているものを読むことができます。
    公開されている原文　https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
    （こちらで和訳されている方がいらっしゃいます。　http://blog.benkyoenkai.org/2011/12/2011-12-1613it.html）

    基本を学ぶという意味では、もちろんこちらの論文を読んでいただいたほうが良いですが、重要な内容を、３ポイントほどにわけて書いてみました。下の記事も読んでいただければ、論文の内容がわかりやすくなるかもしれません。

    1. 論文の書かれた背景


    まずは、論文の内容に入っていくまえに、論文が書かれた背景を理解しなくてはいけませんね。
    １つ目のポイントは論文の書かれた時代背景です。

    この論文はタイトルにあるように、大規模な共用のデータ保存システムの構想をテーマとしています。
    当時存在していたデータベースは、階層型あるいはネットワーク型と呼ばれるようなものでしたが、Coddが提案するRDBはこれら既存のデータベースの短所を克服する特長を持っていました。
    論文中では、1.2 DATA DEPENDENCIES IN PRESENT SYSTEMS でその当時の現行システムの実装についてふれられていますので、この辺りを中心に見ていきましょう。

    その当時のデータベースは、ディレクトリのように配置されたファイルにデータを保存したり、あるいはそれらをネットワークのようにポインタで接続してデータを表現するような構造を持っていました。(例としてあげられている階層型データベースのIMSなどは現在でも利用されています。)
    こうしたデータモデルでつくられた当時のデータベースの短所を、Coddは以下のようにまとめています。

    • Ordering Dependence (レコードの保存順への依存)
    • Indexing Dependence (インデックスの参照方法への依存)
    • Access Path Dependence (データへのアクセス経路への依存)

    ここで依存といわれているのは、アプリケーションがDBに問い合わせするときに、上記の３つのようなDBの内部構造に依存して問い合わせをしてしまうということです。
    つまり、当時のDBでは、データのレコードの保存順やインデックス、アクセス経路などを、アプリケーションが明示的に考慮して処理する必要があり、それに合わせた作りこみをする必要があったわけです。
    現在のRDBであれば、レコードの保存順やデータへのアクセス経路、インデックスなどは、RDBMSが管理してくれるものであって、その変更がアプリケーションの作りに影響することはありません。今では当然に思えるような機能も、当時のデータベースの短所が、リレーショナルモデルという新しいデータモデルによって克服され、可能になったものだったのです。


    2. データをリレーションとして保管するとは


    ではリレーショナルモデル以降から実現された特長がどのようなものか読んだ上で、肝心のリレーショナルモデルがどのようにデータを保管するのか見てみましょう。

    リレーションと呼ばれているものが何であるかは、論文では、1.3 A RELATIONAL VIEW OF DATA に説明があります。そこでは「リレーション」とは数学用語でいうところのそれと定義を同じくするものだと書かれています。
    「リレーション」としてデータを保管するとはどのようなことなのでしょうか。

    まず、リレーションの定義は、「Rは、デカルト積 S1×S2×...×Snの部分集合である」というものです。
    （Rというのはリレーションのこと、Sというのはそのリレーションがもつ個々の要素の集合です。）

    例えば、果物に関する属性が３つあり、それぞれ「名前」「味」「色」だとします。
    --------------------------------
    S1 = { リンゴ, ミカン, メロン }
    S2 = { あまい, すっぱい }
    S3 = { 赤, 黄, 緑 }
    --------------------------------
    ※果物の名前や色が３つしかない、味の種類が２つしかないというのはおかしいかもしれませんが、単純化するためにこう考えてみましょう。

    それではこの３つの集合（S1, S2, S3）を使ってデカルト積をとります。デカルト積というのは、複数の集合からそれぞれ任意の要素を取ったときの、すべての組の集合のことになります。
    ですから、３つの集合からは、
    ----------------------------------------
    リンゴ あまい 赤
    リンゴ あまい 黄
    リンゴ あまい 緑
    リンゴ すっぱい 赤
    リンゴ すっぱい 黄
    リンゴ すっぱい 緑
    ミカン あまい 赤
    ミカン あまい 黄
    ミカン あまい 緑
    ミカン すっぱい 赤
    ・・・・・
    ----------------------------------------
    というようにつづいていく、計18個の組み合わせ要素からなる集合ができます。これがデカルト積です。

    さらに、リレーションの定義はこのデカルト積の”部分集合"というものでした。
    先ほど計18個組み合わせを作ったところからもわかるように属性のデカルト積の組すべてが存在する（真である）わけでないことがあります。(データベースについて言えば、存在しないデータとは記録されないデータのことですから、例えば「ミカン あまい 緑」というデータが保管されないならばそれは真でないということになります。)

    このようにして、集合（属性）を組み合わせた結果から真であるところのものを残した結果がリレーションと呼ばれるものになります。
    ここで重要なのは、「果物の名前」「味」といった属性も集合であり、その組み合わせでできるリレーションも集合である、というようにデータが集合から成るようにできていることです。

    結果、出来上がった「リレーション」は普通の表のような見た目になっています。
    しかし、リレーションとしてデータを持つことで、それまではありえなかったデータに対する操作が実現されるようになります。リレーションが集合であるという特徴から、それに対して集合演算を行うことができるようになるのです。集合演算の内容は論文中では、2.1 OPERATIONS ON RELATIONS の内容にあたります。

    これは、データベースの勉強をし始めるときにでてきた「射影」だとか「制限」、「結合」のような操作のことです。
    SQLだと、SELECT文のなかで、SELECT句に対象の列を指定するのは「射影」、INNER JOIN句の指定は「結合」、WHERE句で条件を設定するのは「制限」にあたります。
    こうした記述は普段SQLを書くときに当たり前のように使うものですが、これが可能になるのも、リレーショナルモデルがデータを集合として取り扱うモデルだからです。保管されたデータを、その保管形式によらず、クエリ言語によって自由に成形して出力できるのはCoddが提案した新しいデータモデルがなくてはありえないことだったのです。

    Coddはこの論文で、リレーションとしてデータを保管することを提案したわけですが、それは逆に言えば人間が記録したいと考えるデータはすべていくつかの属性の要素を組み合わせたものだという気づきに基づくものです。
    データベースの設計において新しいデータモデルを構想するというのは、いわば人間が記録するという一般的な営為全体を要件としてとらえてそれを実現する設計を行うということです。Coddはこの大きな問いに対して一つ回答することができたのです。

    3. リレーションへの問い合わせ言語


    ここまで、リレーションの考え方をDBに適用するアイデアの部分を見てきましたが、リレーションから自由に集合を取り出せるとしても、その問い合わせ方法を形式化できるのかという課題がまだあります。そこで、Coddはもう少しリレーションに対する問い合わせの方法についても、アイデアを持っていました。
    ３つ目のポイントとして、リレーションに対するクエリの方式について書かれた部分、論文中では、1.5 SOME LINGUISTIC ASPECTS の内容を見ていきます。

    ここでは、複数個のリレーションに対して問い合わせを行い、操作者が望むデータの集合を返す言語が構想されています。
    データがリレーションとして保管されていれば、「述語論理」にもとづいた方式で問い合わせをできるだろう、とCoddは構想していました。

    ここで述語論理という言葉が出てきましたが、言い換えれば、何らかの論理式により問い合わせができるということを意味しています。
    述語論理に基づいた論理式では、「すべての…について…である」というような記述をすることができます。（例えば「すべての色について黄色である果物」というように。）そして、述語論理を解釈することによって得られる結果は何らかの集合です。（例えば上の式からは「黄色い果物」の集合が得られます。）
    ですから、データがリレーションとして保管されていることは、集合演算を行えるというだけではなく、そのクエリを述語論理に基づいた式として記述できるという特長ももたらすことになります。リレーションとしてデータを保管しておけば、自由に表を作り出せるだけでなく、論理式で表現できるような望むデータを自由に取り出せるようになるのです。

    ただ、述語論理に基づいて問い合わせを行うためには、条件があります。それはリレーションに含まれる要素の組（テーブル上の１行）が命題として成立するものであって、リレーションが命題の集合であることです。
    例えば、先ほどの例にあった果物のテーブルは、それぞれの行を「名前がりんごの赤色であまい果物が存在する」という様な命題だとしてとらえることができます。その結果「すべての色が赤である果物」というような式を解釈して、その結果の要素として合致する命題を含めることができます。
    論文では1.4 NORMAL FORM に正規形についての言及がありますが、このような操作を可能にするためにはリレーションは正規形(第一正規形)である必要があります。第一正規形すら満たしていないテーブルだと、リレーションを命題の集合としてとらえることができません。

    まとめると、RDBにおいて、テーブルの行と呼ばれているものは、ある命題であり、くだけた言い方をすれば、RDBにおいては保存されるデータの最小単位は、何らかの記述というか「文」のようなものであるといえます。
    一つ一つのデータが文のような表現であることが可能なために、RDBは非常に柔軟な表現力をもってデータを保存することができます。しかし、同時にその一つのデータ（行）はある集合の一要素であることが明確に定義されているために、集合演算や述語論理による問いあわせの対象とすることができます。
    このように、表現力を持ちつつ定式化も行われるという優れたデータモデルをCoddは提案していたのです。

    これらのアイデアは当時の既存のDBの問題点を一気に解消するものであったという実務的な側面もありますが、これだけ深い問題の解決ができる構想をCoddが提示できたのは、人間が何かを記録し、参照する営為それ自体を一般化して設計に反映したからではないでしょうか。
    Coddが定義した人間の営為においては、データとは人間にとって何らか有意味な命題であり、参照はその命題の集合に対しておこなわれます。こうしたものの見方はもちろん数学や論理学を出発点としたものだといえばそのとおりですが、「人間」が何かの記録を保管するときその記録の最小単位は何なのかという問いがなくては得ることのできない視点であったように思えます。

    この論文の発表当時はまだRDBの実装も業務への利用も始まっていませんでしたが、それでもこれだけ完成された構想をすることができたのは、理論的な面での基礎が固められていたことと同時に、そのような人間の営為に対する洞察があったからではないだろうかと思えてきます。

    この論文をよむことでデータベースについての基礎を学べるのはもちろんですが、こうした普遍的な人間の行為に対してもシステムを設計できるのだということに、IT技術が持つ深みのようなものを感じられる気がしています。
    ぜひ、論文のほうも実際に読んでいただき、このあたりの深みも味わっていただければと思います。


    シャノンでは、技術的深みを味わうのが大好きなメンバーを募集中です。




    ↧

    AWSで実現するシャノンのSelenium自動テスト環境のその後

    June 6, 2016, 6:23 pm
    $
    0
    0

    生産性チームのkmtです。
    シャノンでは比較的早い段階から自動テストに取り組んできました。


    過去の記事はコチラ






    順調にテストケースが増えるなか、いくつかの課題を解決するために、自動化環境の改善を行いましたのでその概要をお伝えしたいと思います。

    今回解決を目指した課題は以下の3つです。


    1.いつでもどのチームでもこの環境を利用できるようにスケールさせたい

    QAではリリース前に数台のAWS環境で自動テストを流していたのですが、もう1台増やしたいなあというときにあの設定忘れてた、あれ入れ忘れてる等がありなかなかスムーズに増やせる状況ではありませんでした。
    年々テストは増え、実行時間も少しずつ長くなってきたのですが通常の業務が忙しいとまだ大丈夫かな？と二の足を踏んでなかなか追加のテスト環境を増やせませんでした。

    また

    少人数でスクラムチームを組んでおり、多数のプロジェクトが同時並行ですすんでいます。
    当然リリース時期がかぶったりするのですが、各チームで一部の自動化は流してはいるものの最終的にリリースブランチに統合しないと自動化が全て流れませんでした。
    その結果最後に不具合が発見されることがありました。

    それらを解消したいというのが今回の目標の1つでした。


    2.テスト実行時間を削減したい

    大量のテストを今以上に早い時間で確認して、開発チームの人たちに安心して素早いリリースを実施してもらいたいというのが2つめの目標でした。


    3.ついでに、ここ数年運用していて煩わしい部分はなるべく解消したい

    ここを改修したいとかJenkinsをバージョンアップしたいとかいろいろあったのですが、弊社の開発エンジニアの人数も増え、リリースのためのテストをしつつ環境のメンテナンスをするのが難しい状況でした。
    このチャンスにそのあたりもついでに解消したいというのが3つめの目標でした。

    ただし
    なるべく少ない工数で実施したいので、全体の仕組みを大きくは変えないという制約をつけました。
    あれもこれもやりすぎるとやはり工数がかかってしまうのでどこかで線引きをする必要があるためです。




    これらの目標を少ない工数で改善する為に今回選択したのがAWSのイメージをコピーしてスケールさせる方法です。

    1. ベースイメージとなるインスタンスとAMIを作成しておきます。
    2. チームは環境が必要になったら1.のベースイメージから自分のチーム用のインスタンスを作成します。(masterイメージ)
    3. 上記実施後、自動テスト実行JenkinsJOBを実行すると指定した台数分自分のチーム用のインスタンス（AMI）をコピーしてインスタンスを作成し各AWSでテストが実行されます。
    4. テストが終了したAWSは結果をS3を通して、masterイメージに同期しその後、Terminateされます。
    5. チームメンバーはmasterイメージのJenkinsを参照して自動テストの結果を確認します。




    シャノンでは以前からAWSを使用しているので基本的な部分を変更することなく簡単にスケールできるのですが
    今回の対応でテストを実施するクライアントもAWSの中にいれてしまいました。
    （以前はサーバはAWS、クライアントは別のレンタルサーバを利用していました。）
    サーバとクライアントが分かれているとネットワークや運用で面倒だなといった部分もあったのですが、今回の対応で1つのAWSでテストが完結するのでスッキリとした作りになりました。


    注意するポイント

    1. 1つのAWSイメージが大きくなるとコピーするので課金もそれなりになってきます。1つのAWSでどれくらいのテストを流すのか運用を明確にしましょう。
    2. 繰り返しテストを流すとごみがたまりすぐ容量が一杯になるのでとにかくごみを消すスクリプトをいれましょう。

    今後の課題


    1. 各テストの実施前の準備がまだ結構かかっていること。　DBの復元等、APIではなくDBを復元するツールを作成して使用していますが、複数のDBの復元を実行するとやはり時間がかかってしまっています。
    2. 1つのAWSイメージが大きいとコピーするので課金がコストが増えてしまうこと。DBのチューニングや運用方法の見直しでサイズをもう少し小さくできるのではないかと考えています。

    最後に
    今後も環境の課題はでてくると思いますが、AWSやJenkinsをつかって安定した自動化テストをまわせるような取り組みを継続してできればなと思っています。







    ↧
    Search

    私とキーボード 〜余は如何にしてErgoDoxerとなりし乎〜

    June 10, 2016, 5:29 am
    $
    0
    0
    こんにちは！ ueharak です。

    2016/06/10(金) におこなわれた ErgoDox users meet up の LT 資料です。



    スライドにも書きましたがキーボードの終わりなき旅を一緒に歩んでくれる方を絶賛募集中です！！




    ↧

    YAPCで粘り強くLTしてきた話 #yapc8oji

    July 3, 2016, 5:25 am
    $
    0
    0
    こんばんは！ ueharak です。
    7/3 に行われた YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa で LTしてきました。


    実はわたくし、昨日まで入院していました。予定通りの退院でしたが、ギリギリで綱渡りのスケジュールでした。実際はちょっと遅れてしまい、順番を入れ替えていただくなどご迷惑をおかけしました（ご対応いただきありがとうございました！）。

    入院していて思ったのは「いのち短し　恋せよ乙女」、まさに志村喬の心境です。病院、しかも病棟にはずっしりとした空気が立ち込めていて、よほど気を張らないと押しつぶされてしまいます。そんななか「退院したら LT するぞ」というのはとてもよい目標となり、ベッドの上であれこれと考えることで張り合いを保つことができました。YAPC は病をも治す!!

    そんな私が今回病床でとても役に立ったのは Kindle Oasis でした。これは Kindle シリーズの最新作で、本体とカバーに分離できるタイプのモデルです。この分離できるメリット、いままで感じていなかったのですが、ベッドの上でずっと本を読み続けるというシナリオには大正解であると感じました。

    すなわち分離した本体はシリーズで一番の軽さを誇り、片手を点滴に取られていても易々と持ち続けることが可能です。そしてカバー側には潤沢なバッテリーがついており、読むのに疲れた時にこれらを結合すると本体側へ給電されるという大変すぐれた設計であったというわけです。Oasis の設計者は入院していたのではないか？と思うほどぴったりのユースケースでした。

    入院中は下記を読みました。

    • 『ひらめきはカオスから生まれる』
    • 『あなたの人生の物語』
    • 『SOFT SKILLS　ソフトウェア開発者の人生マニュアル』
    • 『「事務ミス」をナメるな！』
    • 『モチベーション３．０　持続する「やる気！」をいかに引き出すか』

    啓発系が多いのは意図したところで、重い空気に負けない気持ちを保つには己を鼓舞し続けてくれるコンテンツが有効でした。特に SOFT SKILLS、モチベーション３．０ には大いに勇気付けられ、退院してからのあれこれを考えさせてくれる素晴らしい内容でした。

    YAPC 主催の @uzullaさんも仰っていましたが、楽しいと思ったことをする、それが何よりも大切であると痛感した今回の一連のイベントでした。

    楽しいと思ったことをすぐやる。今やる。そういった心もちが何よりも大切です。LT も思い立ったらすぐ申し込む。やれそうだと一ミリでも感じたらやる。そうした意気込みが己を鼓舞し続けるわけです。

    そうして少しずつでも前進していくことが何よりも大切です。今日一歩進めていなければ、千日後に千歩進んだことにならない！まずはその一歩が大切なのです。

    enjoy!!


    一緒に一歩ずつ進んでくれるそこのアナタを待っています!!
    http://carrier.shanon.co.jp


    ↧
    ↧

    JavaScript Puzzlers 2016 Summer

    July 10, 2016, 4:00 pm
    $
    0
    0

    あれ、もう2016年も半年過ぎたの？暑いですね。。。
    どうも、 munepom (@__munepom__) です。
    最近はお仕事で JavaScript をがっつり書いてます。
    先月の社内勉強会でちょっとしたクイズをやったので、今回はみなさまにもトライしていただきたいなー、と。

    てなわけで、 JavaScript Puzzlers 2016年夏の陣でございます。

    Puzzler ご存知でしょうか？
    あるプログラムの実行結果がどのようなものになるかを
    複数の選択肢の中から答える、
    クイズ形式の問題（パズル）のことです。

    今回は、 ECMA 262 (6.0)の挙動ベースで考えてください。
    PC 版の Firefox, Chrome (それぞれ 2016-07-10 の最新版) での動作結果を答えとします。 IE ? ナニソレ。。。

    では、スタート！

    Q1: What's the result?

    var fragment = 'Flag'; console.log('Hello ' + (fragment === 'Flag') ? 'World' : 'none' );
    World
    Hello World
    Hello none
    others
    1. 先に 'Hello ' + (fragment === 'Flag') を評価します
    2. 'Hello true' ? 'World' : 'none'を評価します
    3. 'World'となります

    Q2: What's the result?

    var nullpo = [typeof null, null instanceof Object]; console.log(nullpo);
    ["object", false]
    ["object", true]
    [undefined, false]
    others
    JavaScript の最初の実装では、値は、型を表す「タグ」と「値そのもの」で表されていました。
    オブジェクトの型タグは 0 で。
    で、 null のそれは NULL ポインタ（0x00 は殆どのプラットフォームに存在する）で示されていました。
    その為 Null の型タグは 0 と見做され、typeof null === 'object'となります。

    Q3: What's the result?

    var is_same = [] == []; console.log(is_same);
    true
    false
    error
    others
    [] = new Array(0)
    つまり、 Array のインスタンスとなります。
    今回は、それぞれ異なるインスタンス同士の比較となりますので、評価結果は false です。

    Q4: What's the result?

    var user_name = 'munepom'; (function(){ if (typeof user_name === 'undefined') { var user_name = 'fushiana-san'; alert(user_name); } else { alert(user_name); } })();
    munepom
    undefined
    fushiana-san
    others
    var user_name = 'munepom'; (function(){ var user_name; // 実行時(?)、 Closure 内で、最初に変数が undefined 状態で定義され、評価されてしまいます if (typeof user_name === 'undefined') { user_name = 'fushiana-san'; alert(user_name); } else { alert(user_name); } })();

    Q5: What's the result?

    var end = 9007199254740992; // Math.pow(2, 53); var start = end - 2; var count = 0; var i = 0; for (i = start; i <= end; i++) { count++; } console.log(count);
    2
    3
    0
    others
    var end = 9007199254740992; // IEEE754 で定義される最大値を超える値 var start = end - 2; var count = 0; var i = 0; for (i = start; i <= end; i++) { // 9007199254740992 === 9007199254740993 と評価されます // 加算は止まらず、評価結果は true のままなので、無限ループに突入します count++; } console.log(count);

    Q6: What's the result?

    console.log( 0.8 - 0.6 === 0.2, 0.5 - 0.3 === 0.2, 0.5 - 0.28 === 0.22, 0.5 - 0.25 === 0.25 );
    true true true true
    true false false true
    false true false true
    others
    IEEE754 という計算規格で計算された結果ですが、 0.5 や 0.25 のように、キリ良く 2 進数変換できるもの以外は、 たまたま計算が合うものと思っておくと良いかと。。。

    Q7: What's the result?

    var a = [[0]]; if (a) { if (a == true) { console.log("sweet"); } else { console.log("rotten"); } } else { console.log("why!?"); }
    sweet
    rotten
    why!?
    others
    Array の 古典的な WTF (What's The F***)
    Array が判定にかけられる場合、要素が 1 つだけの場合は、 Array の中身を剥いでいき、、、
    最終的に要素が 1 つだけの場合は、その値と比較が行われるようです。
    お気をつけて。

    Q8: What's the result?

    var int_arr = ["1", "1", "1"].map(parseInt); console.log(int_arr);
    [1, 1, 1]
    [NaN, NaN, NaN]
    [1, NaN, 1]
    others
    ["1", "1", "1"].map(parseInt); ↓ ["1", "1", "1"].map((elm, idx, arr) => parseInt); ↓ ["1", "1", "1"].map((elm, idx, arr) => parseInt(elm, idx)); ↓ ["1", "1", "1"].map(function(elm, idx, arr) { return parseInt(elm, idx) }); ↓ [parseInt("1", 0) parseInt("1", 1) parseInt("1", 2)] = [1, Nan, 1]

    Q9: What's the result?

    var event = new Event('arrow'); window.addEventListener('arrow', function(e){ 'use strict'; console.log(typeof this); var func = function(){ console.log(typeof this) }; func(); var arrow = () => { console.log(typeof this) }; arrow(); }); window.dispatchEvent(event); // fire event
    object, object, object
    object, undefined, object
    object, undefined, undefined
    others
    var event = new Event('arrow'); window.addEventListener('arrow', function(e){ 'use strict'; console.log(typeof this); // Window Object var func = function(){ console.log(typeof this); // この匿名 closure の this を参照します。 // strict モードなら undefined (通常は Window Object) }; func(); var arrow = () => { console.log(typeof this); // same as this in listener (Window Object) }; arrow(); }); window.dispatchEvent(event);

    Q10: What's the result?

    (ᆞωᆞ)=_=3; var puni = (ᆞωᆞ).o-3; console.log(puni);
    0
    3
    NaN
    others
    (ᆞωᆞ)=_=3; ↓ (ᆞωᆞ)=3; ↓ ᆞωᆞ=3; (ᆞωᆞ).o-3; ↓ ᆞωᆞ.o-3; ↓ undefined-3; ↓ NaN

    いかがでしたか？
    顔文字系の問題で
    ╭( ･ㅂ･)و ̑̑ ｸﾞｯ !
    が使えなかったのが心残りでしたが、問題作ってみると良い勉強になりますね。

    もっとすげぇ Puzzler 作るよ！という方！ぜひ一緒に開発しましょ！
    SHANON Carrier Site | 株式会社 シャノン 採用ページ

    Enjoy! ╭( ･ㅂ･)و ̑̑ ｸﾞｯ !

    ↧

    らいとにんぐとーく (LT) はじめました #gatlingtalk

    July 28, 2016, 10:13 pm
    $
    0
    0

    こんにちは、 @__munepom__ です。
    タイトルは冷やし中華はじめました的な何かです。

    梅雨明け進んでますね！夏ですね！ひゃっほー！

    先日、 『Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！』 #gatlingtalk
    という勉強会に参加しまして。

    頭を休める間もないほどのガトリングトークでびびった後、
    懇親会の場でおいしいビールをいただきながら、人生初の外部勉強会 LT デビューしてきましたー。

    私はシャノンに入社して、今月でちょうど１年経ったのですが、、、
    スクラム経験はまだ１年にも満たない、という経験の浅さです。

    でも、何か話してみたい！という衝動に駆られて、 LT やってみました。
    自分のこの半年を振り返る良い機会にもなりましたw

    セプテーニ さんの広いカフェスペース、素敵ですね！
    CyberZ さん、 オプト さん、 セプテーニ さん、アツい勉強会を開催していただき、ありがとうございます！

    がっつりスクラム組んで開発したい方、ぜひご一緒に！開発しましょー！
    SHANON Carrier Site | 株式会社 シャノン 採用ページ

    Enjoy!!! Summer!!! ╭( ･ㅂ･)و ̑̑ ｸﾞｯ !

    ↧

    プログラミング事始め～社内Perl勉強会始めました～

    September 8, 2016, 11:23 pm
    $
    0
    0
    こんにちわ。ishikawaです。

    夏が終わってしまいましたね。
    小学生の時、夏の間のプールが嫌でした。
    泳げなかったので。
    泳げなかった理由、それは単に泳がなかったからだと、今は思っています。

    泳げるようになるためには、泳がなくてはなりません。
    プログラミングできるようになるには、プログラミングしなければなりません。

    ということで、
    社内でPerl勉強会を始めました。（全然つながっていない・・・）

    弊社のメインプロダクトはPerl製です。
    今年、弊社技術部に新卒のエンジニアが2名入ってくれました！！
    また、中途で入ったメンバもPerlの経験がない人が多かったため、
    より深い知識の習得、情報共有、コミュニケーションの場として、勉強会を開くことにしました。


    日時・場所

    毎週木曜 19:00 - 20:00(くらい)
    場所: 弊社会議室


    内容

    テキストは、本家Perl入学式（http://www.perl-entrance.org/）のものを使用。


    参加資格

    新卒の2人がメインターゲットですが、特に制限なし。
    「Perl 何となく書いてるのでちゃんと知りたい」みたいな人も大歓迎！！


    やり方

    1. 講義は特にやらない(各自前もって予習しておく)
    2. 予習して分からなかったことを講師（現Perl入学式スタッフ土田さん）に聞く
    3. 演習問題を解く
    予め予習してから演習問題に取り組むので、1時間の勉強会で、Perl入学式の1回分を消化する感じのスピードで行っています。


    実際の風景

    （枠は本家Perl入学式のものをお借りしました！）

    やってみた感想

    新卒と自然と会話が生まれる

    同じプロジェクトにならないと、新卒の2人と接する機会はほとんどなかったりしますが、
    勉強会を通して、自然と会話が生まれ、お互いの人となりを知る良いきっかけとなっている気がします。先日の勉強会で、新卒の人が「ここの住所が・・・」と言っていて、なんのことかなと思ったら、Perlのリファレンスのことを言ってて、確かに間違っていないと思いました。

    講師がその場でライブコーディングしてくれるのでわかりやすくて面白い

    現Perl入学式スタッフ土田さんが課題を説明しながら、その場でライブコーディングして、デモしながら説明してくれます。ライブコーディング、見ているだけで楽しいですよね？知らなかったコマンドやツールも会話の中で気軽に聞けるので、個人的にはとてもありがたい場となっています。


    ---

    友人に、「どうしたらプログラミングできるようになるの？」と聞かれたりすることがあるのですが、
    私もどうしたらできるようになるかは、今だにわかりません（笑）
    ただ、一つ言えるのは始めること、始めたら続けることが大切だとは思っています。
    （どんなことでも同じですね。。）

    Perl勉強会はまだ始めたばかりですが、いろいろな気づきと新たなコミュニケーションの場として、みんなで楽しい時間を過ごしています。

    気になる方、この秋、プログラミング始めてみてはどうでしょうか？
    ↧
    Viewing all 210 articles
    Browse latest View live
    Search