はてなに入って半年が経ちました〜半年目線〜
こんにちは、はてなでMackerelセールスエンジニアをしている
id:sharataniです。
はてなスタッフアドベントカレンダーの一環で「はてな」に関することをテーマにしてブログ記事を書くこととなりました。
昨日は
id:Swatzさんと
id:mohritarohさんでした
自己紹介
私は今年の6月に渋谷にある会社を退職し、同月にはてなに入社しました。
まさかはてなに入社するとは思っていなかったので、30超えても人生何が起きるか分からないものだなと感慨深かったのを覚えています。
応募〜入社までも色々とありました。
何やってるの？
MackerelというSaaSのサーバー・パフォーマンス監視サービスのセールスエンジニアとして働いています。
セールスエンジニアという職種は私だけなのですが、そちらの話ははてなデベロッパーアドベントカレンダーの時に書こうと思います。
developer.hatenastaff.com
何書くの？
「はてな」は2001年創業のため、インターネット系ベンチャー企業としては歴史もあり、インターネット上で色々な情報が見つかります。
しかし、あまり知られていない（単に自分自身が入社するまで知らなかったのかも）こともあり、この半年での気づきなどを簡単にまとめてみたいと思います。
１．入社時に好きなPCが選べる
エンジニア・デザイナー系とそれ以外の職種で分かれるようですが、一定の範囲内で好きなPCを選ぶことができます。
個人的な所感ですが、エンジニア・デザイナーはMacが多い、ビジネス系（営業・コーポレート）はWindowsが多いという印象です。
２．マウス・キーボードの購入に補助が出る
入社時に一定の範囲内で好きなPCを選べる会社は増えていますが、マウス・キーボードの購入に関して補助が出る会社はあまりないように思います。
手に馴染んだものを使いたいからちょっとお金を出しても自分が使いやすいものを購入する、そんな人は多いのではないでしょうか？
結構な金額の補助が出るので、自前で用意する人にとっては地味に有り難いです。
自前で買いましたが、私は会社では有線のApple キーボードとロジクールのMX Masterを使っています。
３．好きな椅子を選べる
インターネット系企業ではエンジニア向けによく見られる福利厚生の一つですが、はてなではアーロンチェアを用意しています。
しかし私の場合はアーロンチェアの後ろに沈み込む感覚がダメだったため、オカムラのシルフィに座って仕事をしています。
こちらも一定の金額内であれば会社から用意してもらえるため、快適に仕事ができます。
社内では椅子の代わりにバランスボールで仕事をしている人も結構多いです。
４．帰宅が早い
はてなは10時始業、19時終業なのですが、残って仕事をしている人の方が珍しくて目立つ、というぐらいに、みんな帰宅が早いです。（残業代が出ないというわけではない）
仕事をうまくこなしつつ、プライベートでの過ごし方も充実しているという人がとても多いように感じます。
５．社内ではIDで呼んでいる
なので本名を知らない・忘れる、などがたまにあったりします。
最初はびっくりしましたが、慣れるとそれが普通になってしまいます。慣れって怖い。
Mackerelのドリンクアップ・ミートアップといったイベントの懇親会でお客さんへエンジニアを紹介することもあるのですが、紹介するエンジニアの名字がうっかり出てこないこともあったりなかったりします。
IDなのであだ名とはちょっと違うかもしれませんが、名字で呼び合うよりも親近感がわくように思います。
渋谷のとある企業もあだなで呼び合う文化だと聞いたことがありますが、そういったことも社内の雰囲気の良さに一役買っているのかもしれません。
６．衣類が支給される（福利厚生の一環）
毎年一般販売される「はてなTシャツ」ですが、従業員にも福利厚生の一環として好きなデザイン・好きなサイズのものが支給されます。
私が所属しているMackerelチームではMackerelポロシャツ・Mackerelパーカーなどもあり、こちらも支給されます。（イベントとかで着てるやつです）
７．自席以外でも自由に仕事ができる
はてなには3FにSHIBAFUとよばれる多目的ルームがあるのですが、SHIBAFUにあるテントやリクライニングベッド（っぽいもの）で仕事をすることもできます。
来社いただいた方とTATAMI（掘りごたつのある会議室）やSHIBAFUで打ち合わせをすることもありますが、もちろん部屋が空いていればTATAMIで仕事をすることもできます。
基本的にノートPC＋27インチの外部ディスプレイという環境なので、PCさえあれば社内のどこでも仕事ができるという感じです。
８．何だかんだで京都に行く機会が多い
チームや職種によっても変わってきますが、何だかんだで月に1〜2度は京都本社に行っています。
Mackerel自体が関西圏でも知名度・認知度が上がりつつあることもあったり、京都・愛知にも開発メンバーがいるので顔を合わせようという一環でもあります。
たまに「京都観光が出来て羨ましい」と言われることもありますが、仕事が終わるのは19時で東京に帰ろうと思うと21時半が終電なので、あんまりそういうものでもなかったりします。
９．あまりお金を使わなくなった
前職では渋谷勤務だったため、昼ご飯は桜丘や渋谷駅近辺が多かったです。
だいたい800円〜1000円の間で昼ご飯を食べることが多く、1ヶ月に換算すると1万6千円〜2万円の出費になります。
しかしはてなでは昼食に毎日まかないランチがでて、飲み物（お茶・コーヒー・ジュース）もお菓子類も自由なので、あまりお金を使わなくなりました。
たまに外出先で昼食を食べる際は昼ご飯にお金を出すということにハッとします。
※まかないランチは強制ではなく自由なので、外に出て食べてもいいのですが、青山ではほぼ100%の人がまかないランチを食べてます
１０．季節感を感じることが多い
仕事の忙しさなどで季節感を感じるということではなく、社内のイベントやちょっとしたことでも季節感を感じることが多いです。
今の時期ではクリスマスが近いこともあり、この前出社したら入り口の受付にクリスマスツリーが飾ってありました。
あまり知られていませんが、ハロウィンの時期には社内で仮装コンテストが開かれたりもします（テレビでも取材されました）
などなど、会社によっては一部の福利厚生の対象がエンジニアだけが対象ということもありますが、はてなではあまりそういうこともなく、とても過ごしやすい・働きやすい良い会社です。
私のはてなとの出会い
個人的な話ですが、私が会社としての「はてな」を知ったのは、10年ほど前にITmediaに掲載されたこの記事でした。
www.itmedia.co.jp
当時は単純に
id:naoyaさんというすごい人が、はてなという変わった名前の会社に入社して、なんかすごいことをやっているんだろうという認識でした。
当時は「自分には無縁だな」と思っていましたが、あれから10年経ち、社内・社外のスゴイ人たちと一緒に仕事をしています。
何をやるのか、何ができるのかは仕事をする上でとても大事なことですが、誰とやるかというのも同じぐらいとてもとても大事なことだと思います。
「はてな」ではエンジニアと言わず、色々な職種で募集をしています。
もし興味がある方がいましたら、私含むはてなスタッフまで気軽にご連絡いただくか、採用ページからぜひ応募してみてください。
hatenacorp.jp
明日は
id:astjさんと
id:sallymyloveさんです
SQL学び直し１３
第八章：SQLで高度な処理を行う
8-1：ウインドウ関数
- ウインドウ関数とはOLAP（OnLine Analytical Processing）関数とも呼ばれる
- OLAPとはリアルタイムにデータ分析を行う処理のこと
- 構文：ウインドウ関数 OVER ( PARTITION BY <列リスト> ORDER BY <ソート用列リスト>）
- rank over (partition by A orderby B) as ranking from table といった形で使う、A列毎にB列順にrankingカラムでランクを付けてくれる
- ウインドウ関数は集約関数をウインドウ関数として使う、ウインドウ専用関数を使う、の2種類に分けられることができる
- partition byによって区切られたレコードの集合をウインドウと呼ぶ、窓ではなく範囲を表わす
- partition byを使わない場合、テーブル全体が1つのウインドウとしてみなされる（order byのカラム基準になる）
- 以下、各ウインドウ専用関数の違い
- rank()の場合に1位が3つある場合、1位、1位、1位、4位と飛ぶ
- dense_rank()の場合に1位が3つある場合は1位、1位、1位、2位と飛ばない、デンスランクと読む
- row_number()の場合に1位が3つある場合は1位、2位、3位、4位と同じ値でも2位と3位になる、同じ値の場合はDBMSが適当に値を振る
- ウインドウ専用関数を使う時は()の中は空のまま使う、これは全てのウインドウ専用関数で同じ、引数を取らない
- ウインドウ関数h原則としてSELECT句のみで使える、AVGやSUMを利用すると降順・昇順でのその時点での累計や累計の平均を出力出来る
- 移動平均を出す場合
- avg(カラムA) over(order by カラムB rows 直近の何行か数値を入れる preceding) as ~
- その値の直近3行分の平均値をasの中に入れられる、precedingは前のという意味
- カレントレコードから後ろを対象にするには、following（後の）を使う
- 前後を対象にする場合は(order by A rows between 前の分の数値 preceding and 後ろの分の数値 following) as ~とする
- OVER句の中のorder byはウインドウ関数がどういった順序で計算数かを決めるだけの役割しか持っていない、結果の並び替えには影響しない
8-2：GROUPING演算子
- グループ化した結果の合計を求めることができる、ROLLUP、CUBE、GROUPING SETSの3種類がある
- と思ったら、postgresqlではサポートされていないらしい
今日はここまで、長かったけど終わった。
とても勉強になったし、実務でも役立ったし、良い本でした。
SQL学び直し１２
第七章：集合演算
7-2：結合（テーブルを列方向に連結する）
- 結合の基本は内部結合と外部結合
- 内部結合：select ... from A inner join B on A.x = B.y というような構文
- 外部結合：片方のテーブルの情報がすべて出力される
- from A left outer join B on A.x =B.y という場合はテーブルAのデータが全て出力される
- from A right outer join B on A.x =B.y という場合はテーブルBのデータが全て出力される
- クロス結合：select ... from A cross join B というような構文
- すべての組み合わせ（直積）結果を出力する
- 外部結合、クロス結合はあまり使わない
- NULLを他の値に置き換える関数「COALESCE」を併用することが多い
今日はここまで。
SQL学び直し１１
第六章：関数、術語、CASE式
6-3：CASE式
- 単純CASE式と検索CASE式の2種類がある、検索CASE式は単純CASE式の機能を全て含む
- 検索CASE式は以下のような式になる
CASE WHEN <評価式> THEN <式>
WHEN <評価式> THEN <式>...
ELSE <式>
END
- 最後のENDは必須、ELSEは省略しても良いが可読性が落ちるので省略しない
第七章：集合演算
7-1：テーブルの足し算と引き算
- UNION、テーブルの足し算
- select AAA from B union select CCC from D; というような感じになる、重複行を排除して各テーブルが合体されたものが表示される
- UNION ALLで重複行も表示される
- INTERSECT、テーブルの共通部分のみ抽出
- select AAA from B intersect select CCC from D; というような感じになる、共通しているレコードのみ出力される
- EXCEPT、レコードの引き算
- select AAA from B except select CCC from D; というような感じになる、テーブルBからテーブルDと重複したものを排除して出力される
今日はここまで。
SQL学び直し１０
第六章：関数、術語、CASE式
6-2：術語
- 術語とは戻り値が真理値（TRUE/FALSE/UNKNOWN）のいずれかになるもの
- LIKE検索にて、%は0文字以上の任意の文字列、_は任意の一文字を現す（__だと任意の2文字）
- BETWEENは範囲検索
- IS NULLはnullを検索、IS NOT NULLはnullを外して検索
- INはORを省略したもの、IN(A,B,C)というように使う、AまたはBまたはCとなる
- NOT INはINの否定、NOT IN(A,B,C)というように使う、AでもなくBでもなくCでもないものとなる
- INにはサブクエリを利用することができる
- IN( SELECT...)と記述する、括弧内の結果が複数行であっても全てORで検索対象にしてくれる
- サブクエリを使ってSQLを組んでおけば、メンテナンスフリーの度合いが強まる
- EXISTS術語は「ある条件に合致するレコードの存在有無」を調べる、あればTRUE、なければFALSEを返す
- EXISTSの引数は常に相関サブクエリを指定する、常にSELECT *を使う
今日はここまで。
SQL学び直し９
第六章：関数、術後、CASE式
6-1：いろいろな関数
- 関数は数が多いので代表的なものだけ覚える、他は使う時にリファレンスを見るようにする
- COUNT、SUM、AVGなども関数の一つ（集約関数）
- 文字列を結合する関数はパイプ、カラム1 || カラム2 from…という感じになる、3つでもいける
- EXTRACTで日付の要素を切り出すことが出来る、切り出した後は日付型ではなく数値型になる
- こんな使い方
SELECT CURRENT_TIMESTAMP, EXTRACT(YEAR FROM CURRENT_TIMESTAMP) AS year, EXTRACT(MONTH FROM CURRENT_TIMESTAMP) AS month, EXTRACT(DAY FROM CURRENT_TIMESTAMP) AS day, EXTRACT(HOUR FROM CURRENT_TIMESTAMP) AS hour, EXTRACT(MINUTE FROM CURRENT_TIMESTAMP) AS minute, EXTRACT(SECOND FROM CURRENT_TIMESTAMP) AS second;
- nullを値に変換する際はCOALESCE関数を使う
SQL学び直し８
第五章：複雑な問い合わせ
5-2：サブクエリ
- サブクエリとは使い捨てのビュー
- select ... from (select文を書く) as ビュー名、このビューは保存されない
- fromの中のselect文が実行された後、外側のselect文が実行される
- select ... from （asの後の）ビュー名となる
- サブクエリの中にサブクエリを作って入れ子にすることも可能、内側のサブクエリから実行される
- スカラ・サブクエリとは、戻り値が単一の値（単一行）になるサブクエリのこと
- whereの=や<>の条件などと一緒に使用する
- スカラ・サブクエリはwhere句以外の場所でも利用できる
- スカラ・サブクエリが複数行を返すと、それはスカラ・サブクエリではなくただのサブクエリである
5-3：相関サブクエリ
- 相関サブクエリは小分けにしたグループ内での比較をする時に使う
- 相関サブクエリの結合条件はサブクエリの中に書かないとエラーになる
- 結合条件はサブクエリの中に記述する
今日はここまで。
SQL学び直し７
第四章：データの更新
第五章：複雑な問い合わせ
5-1：ビュー
- ビューを"作る際"order byは使えない、ビューを更新はできなくないが制限がある
- ビューとテーブルはSELECTするだけであれば特に気にする必要が無い
- テーブルはデータを保存・保持している、ビューはデータを保存・保持していない代わりにSELECT文を保持している
- ビューは参照される度にSELECT文を実行し、一時的に仮想のテーブルを作成する
- ビューの実行順序はビューに保持されたSELECT文が実行され、その後にFROMにビューを指定したSELECT文の内容が実行される
- ビューを元にビューを作る、多段ビューも作成できるが、なるべくやらない。パフォーマンスが低下する。
- postgres9.3だけど参考
今日はここまで。
SQL学び直し６
第四章：データの更新
4-2：データの削除（DELETE文の使い方）
- DELETE文は行を削除、TRUNCATE文はテーブル全行を削除
- `DELTE FROM テーブル名`よりも`TRUNCATE テーブル名`の方が処理が高速である
4-3：データの更新（UPDATE文の使い方）
- UPDATE文を使えば、制約に引っかからない場合はNULLへ更新することも可能
- `UPDATE テーブル名 SET 更新内容1,更新内容2...`とすることで、複数列の更新も可能、カンマで区切る
- `UPDATE テーブル名 SET (更新列名1,更新列名2)=(更新データ1,更新データ2)...`とすることで、複数列の更新も可能、カンマと括弧使う
やっぱりUSキーボードよりJISキーボードの方が使いやすい。
慣れの問題もあるんだろうけど、使い慣れたモノを使うのが一番だと思う。
自宅の環境としては、
という無駄に変な環境なので、次期iMacが出たらiMacと液晶1台にして、WinはParalellsとかでまとめたいなぁ。
って夢をメモしておきます。
今日はここまで。
