元岩手県民から見た岩手・宮城・福島の都市の序列

岩手県に18年、福島県に2年弱、宮城には住んだことないけど何回か泊まったことがある程度の人が、この三県にどういう思いを抱いているのかを書いてみる。

岩手

  • なんだかんだで盛岡はそこそこ都会（少なくとも北東北のなかでは）
  • でも駅前しょぼいよね
  • 他の都市（北上とか一関とか）は典型的な地方都市感しかない
  • 沿岸部はお察し下さい
  • 縦の移動は（高速も新幹線もあるから）簡単だけど横の移動が超大変
  • 面積広すぎで例えば「出身は盛岡です」って言っても「盛岡のどこ？」って聞くのがデフォルト
  • 「わんこそば」はそんなに頻繁に食べるものじゃない
  • 「冷麺」「じゃじゃ麺」は結構食う

宮城

  • 大正義仙台シティ
  • 仙台駅周辺が大都会
  • でも、ぶっちゃけ仙台駅周辺（青葉区・宮城野区近辺）以外は知らん
  • 萩の月をおみやげで買っていくと喜ばれる

福島

  • 郡山は都会、福島はそこそこ都会、いわきは人口多い割にはあんまり…
  • 郡山と福島で競い合ってるらしいが、駅前の繁栄ぶりだと郡山が抜きん出てる感
  • 初めて郡山に来た時の印象は「盛岡より大分都会だなー」だった
  • 群馬・三重・山口とかと同じく、交通の要衝が栄えて県庁所在地があんまり、というパターン
  • ここも例に漏れず（郡山⇔いわきを除いて）内陸と沿岸の移動が大変そう
  • 私が住んでいた会津若松市はごくごく普通の地方都市で、住むのに苦労はしないけど遊びたい若者にとってはちょっと退屈かもなーという気もする
  • そういう意味では会津大学は勉強に集中できていい環境である（ということで数学と英語ができるけど他の教科はあんまり・・・という人は会津大学に行こう！！！）

今一度 MySQL forked なプロダクト群についておさらい

MySQL を使っている企業やディストリビューションが続々と MariaDB に鞍替えすることでにわかに活気だってきた MySQL forked なプロダクト達。
今回はそれらを 3 行でまとめてみる。

MySQL

  • 言うまでもないけど本家
  • 現在は Oracle が開発を主導（および権利を保有）しているが、プロプライエタリになったりすることはなく、いまも OSS として開発されている
  • 特にこれと言って言うことはないが、なんだかんだで安心感はある

Percona Server

  • もともと MySQL の専門コンサルだった企業が「俺らが作ればいいんじゃね？」ということで作り始めたプロダクト*1。ちなみに InnoDB を fork した XtraDB の開発元もここ。
  • MySQL との完全互換性を謳っており、既存のコードを置き換えること無く移行可能。僕も前職で MySQL から移行してみましたが全くなにもしませんでした。設定ファイルすら変更しなくてもいいくらいの勢い。
  • 後述の forked プロダクトと違って MySQL の後継というよりは MySQL よりちょっと速い互換製品とも言えなくはない。とりあえず試してみたいならオススメ。

MariaDB

  • MySQL AB の創業者が立ち上げたプロダクト。Percona とほぼ同様、互換性を維持しているので、移行の際に SQL を書き換えたりする必要はなさそう。
  • 開発思想的には、MySQL の forked というよりは作りなおしたプロダクトを元に MySQL に新たに実装されていく機能から「これはユーザー的に欲しいよね」っていう機能を取捨選択して実装していく、みたいな姿勢が伺える。実際、コアなコードは（オリジナルなものから）かなり置き換えが進んでいる模様。
  • 最新バージョンは 10.0（本家の 5.6 の機能にそこそこ追従）。あ、そうそう、Percona と MariaDB は handlersocket を標準搭載しているよ！

Drizzle

  • MySQL forked ではあるんだけど、開発元自身が「もう今は MySQL とは別モンだよ」って言ってるのであんまり互換性には期待しないほうがいいと思われる。
  • じゃあ誰が使うかって言うと、主に高可用性に的を絞って開発されているらしいので、数万 qps とかが絶え間なく来るようなリクエストにも耐えられるような DB サーバーが欲しい！とかそういう場合に使うべき、らしい。
  • ぶっちゃけ普通の用途にはピーキー過ぎて使いづらそうな予感。正直良くわかんない。

*1:だいたい想像

mixi がソーシャルプラットフォームのオープン化に踏み切ったのは Mobage & GREE より前

笠原社長退任にみる、ミクシィの苦悩〜相次ぐ身売り話と人材離脱、ライバルの台頭… | ビジネスジャーナル

そして11年11月、ミクシィは事業方針を大きく転換した。SNS上にミクシィゲームを新設してソーシャルゲームに進出。ビジネスモデルを広告モデルから課金モデルに変更した。しかし、ソーシャルゲームに出遅れたことが響き、グリーやDeNAとの業績の格差は広がった。

とあるんだけど、「いや、2010年春に mixi 向けに会社でソーシャルゲーム*1作ってた記憶あるぞオイ…」と思って調べてみたら、「mixiアプリ」からゲーム部分だけを切り取った「mixiゲーム」というサービスが2011年にできていたらしい。

なので「それ以前から mixi は課金モデルのソーシャルプラットフォームを持っていたけど、更にそっち方面へ舵を切ったのが2011年11月」というのが正しい（はず）。

 

もっと言うと、ソーシャルプラットフォームのオープン化（OpenSocial 化とも言う）は実は mixi が一番早くて（2009年の秋ごろ）、続いて2010年初頭にモバゲー、2010年夏くらいに GREE という順だったと思う。

なので、mixi 自体はソーシャルゲームの波に別に乗り遅れてないけど、モバグリと違ってゲームを自社開発していたわけじゃないし、ソーシャルゲームにはあんまりリソースを配分していなかった*2のがここに至る要因なんじゃない？なんつーか、PS 発売前に出た 3DO とか、そういうポジション。

 

あ、他の部分については特に言うことはないです。

*1:乙女ゲーの類

*2:これは別に戦略として悪いことじゃない、失敗したけど

別にプログラミング自体を目的にしてもいいけど

出来ればある程度プログラミングできるようになってから目的にしてくんねえかな。。。

 

経験上、プログラミングが目的になってる人でエンジニアとして優秀な人が多いのは確かだし、プログラミングがバリバリ出来る人でプログラミングが目的になってる人を否定するつもりは全くないんだけど、全くプログラミングの経験がない人に「とりあえずプログラミング教えてよ！」って言われるとなんかむかつくんです。

 

というわけで、「プログラミングは手段だよね」って言っている人の大体はそういう意味で言ってるだけなので、プログラミングが出来る人から「プログラミングが目的で何が悪い！」とか言われても正直「その調子でがんばってください」としか。。。

三大「なんだこれ！」と思ったWikipediaの項目

日本は侵略国ではありません!

ラノベのタイトルかなにか？

ではなく、94年春に出された意見広告、及び小冊子の名称とのこと。

日本の若者には右寄りの思想の人達が多いらしいので、本当にこういうラノベ出したらそれなりに受けそうですね。

降り懸かる火の粉は拂はねばならぬ

ファンタジーものの悪役のセリフかなにか？

ではなく、これまた小冊子の名称で、ライカとコンタックスのカメラどっちがいいの？という論争が1930年代に日本でぶち上がった最中に出されたそうです。

厨二っぽくていいですね。

アグネス論争

児ポルに関する論争かなにか？

ではなく、アグネス・チャン氏が第一子を出産後、その赤ちゃんを連れてテレビ出演しているのを見て一部の妬んだ女性（※想像です）が「子供を仕事場に連れてくんな！」という「そりゃそうだけど、ここでそれ言う？」的な発言から巻き起こった論争らしいです。

そういえば最近でもどっかの漫画家が飛行機に乗ってくる赤ん坊がうるせえ黙らせろとかなんとか言ってそこそこな論争が巻き起こってましたね。あんまり世の中の流れって変わらないもんですね。

 

退職しました

2013年2月15日をもちまして、株式会社ユードーを退職いたしました。

2011年4月に入社し、2年弱勤務させて頂きました。

 

「そもそもお前はどういう仕事をやってたの？」と思う方もいらっしゃると思いますので、簡単に説明しますと、スマートフォン（iOS、Android向け）アプリのサーバーサイドの開発を全般的にやってました。

 

たとえば、「斉藤さん」というアプリでは最大2000万弱/日、350アクセス/秒というAPIアクセスをフロント・DBサーバー（スペックもそこまで高くないやつ）それぞれ一台で捌くという結構無茶なことをやったりしてました。

また、最後のプロダクトとなった「プチリッチ」というアプリでは初めてRubyに挑戦してみたり、なんだかよくわからないうちにAPI連携のためにソケットプログラミングとかしてみたりして、思いの外複雑なシステムを作り上げちゃったりもしました。

 

あと、前述の「斉藤さん」ではテーマソングを作る際に音ゲーの創始者とも言える人が作曲したものを元に初音ミクの打ち込みを担当させていただいたり、「テガキモンスター」というプロダクトの発表イベントでは、あの「わくわくさん」こと久保田雅人さんとお会いすることができたりして、忘れられない経験をいっぱいさせていただいた気がします。

 

今後についてですが、1週間のブランクを開け、また次の会社で働き始めます。

どうぞ、今後ともよろしくお願い致します。

 

 

 

はてブロ発投稿が退職エントリーってどうなんだろう。。。

「INSERT INTO 〜 SELECT 〜」のSELECT結果を「ON DUPLICATE KEY UPDATE 〜」で使う

「ON DUPLICATE KEY UPDATE」という構文がMySQL独自のものと知ったときは軽くショックを受けました*1。

まあ、そんなことはどうでもいいんです。
通常、「INSERT INTO 〜 SELECT 〜」ってGROUP節を使って集計したものをどっかのテーブルに入れるとかっていう時に使うと思うんですが、その集計結果が既にあるときにUPDATEする、ということがしたいですよね。
例えば次のようなクエリで。

INSERT INTO total (id,count)
SELECT id, count FROM daily GROUP BY date

私は最初次のようにやってみましたが、これはエラーになります。

INSERT INTO total (id,count)
(SELECT id, count FROM daily GROUP BY date) t
ON DUPLICATE KEY UPDATE count = t.count

後から気づいたんですが、そもそもサブクエリ全体に派生テーブル名をつけてどうすんだって話ですね。
正しくはこうです。

INSERT INTO total (id,count)
SELECT id, count FROM (SELECT id, count FROM daily GROUP BY date) t
ON DUPLICATE KEY UPDATE count = t.count

*1:oracleにはMERGEっていう似たものがあるらしいですが詳細は知りません。あとポスグレはストアドプロシージャ使うらしいです