「[京都] テクテクテック #5 フリーランサーにいろいろ聞いてみよう」というイベントで発表してきました。
フリーランスの人が4人集まってそれぞれのことを話しました。 3人がエンジニアで1人が金融系ということで、異業種含め他のフリーランスのことを聞けたのがとてもよかったです。
4人ともいろいろな経緯でフリーランスになったようですが、みんなとりあえず会社やめようって感じで「フリーランスになろう」と思っていたわけじゃないという共通点がありました。
また、仕事も前職のつてや知人の紹介であったりと基本的にコネで仕事をやっていて、特に営業活動していないという部分も同じでした。
正直なところ「これからフリーランスになりたい！」と思っている人にはあまり参考にならない話だったようにも思いますが、一方で気負わずつながりを大事にしていけばフリーランスはなんとかやっていけんだ、ということなのかもしれません。
Blockchain勉強会 in Kyoto #05でMySQL8.0 使いたいからブロックチェーン実装してみたというタイトルで発表してきました。 MySQLを使いたいというモチベーションだったので、ブロックチェーンの話はこじつけではありましたが、発表できてよかったと思います。
スライドはこちら（後日、別の勉強会でも発表したのでアップデートされています）
発表の中でJSON型に保存したカラムの値からMD5のHash値を計算する部分があります。それについて勉強会後に質問されました。 「Oracleが開発してるんできっとちゃんとしてますよねー。」と話していましたが、実際のところはわからなかったので調べることにしました。
データの標準化や正規化を意味する言葉です。例えばJSONの場合同じデータ構造でも文字列にしたときに別のものになってしまうことがあります。
a = { "name": "zorori", "skill": "c++" } b = { "skill": "c++", "name": "zorori" }
aとbは同じname, skill というキーを持ちそれぞれ同じ値を保持しています。
そのためデータの表現としては同じものですが、定義されている順序が異なるため文字列化した時に異なった結果になってしまいます。
// on nodojs // 文字列化しても同じ文字列にならない > JSON.stringify(a) '{"name":"zorori","skill":"c++"}' > JSON.stringify(b) '{"skill":"c++","name":"zorori"}' // オブジェクトの比較も一致しない > a == b false > a === b false
厳密には JavaScript は JSON ではないので注意が必要ですが、JSONを文字列として表現する時、ルールに則って文字列化することで同じデータが異なる文字列にならないようにする必要があります。
これをCanonicalizeといいます。
JavaScriptとJSONの関係についてはこちらを御覧ください。JSON: The JavaScript subset that isn't — Timeless
動作を確認してみましょう。まずは JSON_OBJECT() 関数の動作をみてみます。ドキュメントはこちら。
引数にKey, Value を交互に与えることでJSONオブジェクトを作成します。
mysql> select JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan'); +------------------------------------------------------+ | JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan') | +------------------------------------------------------+ | {"name": "ishishi", "skill": "melon-pan"} | +------------------------------------------------------+ mysql> select JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi'); +------------------------------------------------------+ | JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi') | +------------------------------------------------------+ | {"name": "ishishi", "skill": "melon-pan"} | +------------------------------------------------------+ mysql> select JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi') = JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan') as result; +--------+ | result | +--------+ | 1 | +--------+
mysql> select md5(JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi')) md5 -> union all -> select md5(JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan')) md5; +----------------------------------+ | md5 | +----------------------------------+ | 72e1a15793042e2a7b9f250c7b37f750 | | 72e1a15793042e2a7b9f250c7b37f750 | +----------------------------------+
JSON_OBJECT() の戻り値は入力の順序によらず同じ表現のデータが作成されています。
まずJSON型のカラムをもつTableを用意します。
CREATE TABLE `jdoc` ( `id` int(11) NOT NULL AUTO_INCREMENT, `doc` json DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
データを挿入します。
mysql> insert into jdoc set doc = '{"name":"noshishi", "skill":"onigiri"}'; Query OK, 1 row affected (0.10 sec) mysql> insert into jdoc set doc = '{"skill":"onigiri", "name":"noshishi"}'; Query OK, 1 row affected (0.02 sec) mysql> insert into jdoc set doc = JSON_OBJECT('name', 'noshishi', 'skill', 'onigiri'); Query OK, 1 row affected (0.01 sec)
挿入したデータはそれぞれ違う入力方法です。Tableにはどのように保持されているかを確認します。
mysql> select * from jdoc; +----+------------------------------------------+ | id | doc | +----+------------------------------------------+ | 1 | {"name": "noshishi", "skill": "onigiri"} | | 2 | {"name": "noshishi", "skill": "onigiri"} | | 3 | {"name": "noshishi", "skill": "onigiri"} | +----+------------------------------------------+
どの行も同じ形式のデータのようです。 MD5のハッシュ値も比較してみましょう。
mysql> select id, md5(doc) from jdoc; +----+----------------------------------+ | id | md5(doc) | +----+----------------------------------+ | 1 | 275aceba7931ad3e345e31d48a949e9b | | 2 | 275aceba7931ad3e345e31d48a949e9b | | 3 | 275aceba7931ad3e345e31d48a949e9b | +----+----------------------------------+
ハッシュ値も同じなのでTableに保持されているデータは同じものといえます。
Normalization, Merging, and Autowrapping of JSON Values
ドキュメントには以下のように記述されています。
When a string is parsed and found to be a valid JSON document, it is also normalized. https://dev.mysql.com/doc/refman/8.0/en/json.html#json-normalization
Normalize と表現されていますが、MySQLではJSONは正規化された値が利用されるという記述があります。 また以下に記述されているようにJSON関数は正規化された値を返すようです。
MySQL functions that produce JSON values (see Section 12.16.2, “Functions That Create JSON Values”) always return normalized values.
MySQL8.0でJSONを扱う場合「JSON型を使うことでMySQLが正規化してくれる」ということになるので安心して使えそうです。 めでたし、めでたし。
前回投稿した記事 向こう2年くらいまでの生存戦略 - 主夫ときどきプログラマ を書くに当たり、影響を受けないように読むのを控えていた記事があります。
こちらの記事です。
無事投稿できたので読んでみたら、自分の戦略には発注者視点というものが抜けいました。 これについては働きながら意識している部分がいくつかあるので、せっかくだから書いておこうと思います。 僕の場合は対等に1つのブロジェクトを進めていくという感じでやっているので、パートナーと呼んだほうがしっくりくるのでそうします。
いつも一緒に仕事をするマネージャーさんは開発をするにあたり仕様書をつくってくれます。 けれど、時間的な部分やクライアントの問題もあり抜けや考慮漏れが発生します。
それは仕方のないことだし、それでも開発できないこともないので必要な部分を一つ一つ埋めていく作業をこちらでしてあげると、たいがい喜んでくれます。 ドキュメントがGoogleDocsで作られている場合はこちらで加筆・修正してあげるとなおさら喜んでくれます。
相手が十分なスキルを持つマネージャーやエンジニアの場合、漏れがある原因はだいたいリソース（時間）不足なので、それを補ってあげることを重視します。
一方、相手が若かったり経験が少ない場合は、こちらで補いつつ、叱責し正しい方法などを示してあげます。 これは教育・指導すべき人たちのリソース（時間）不足が原因であることが多いので、そこを補ってあげます。
中小企業と一緒に仕事をしているとリソース不足がよく発生するので、そのへんを補ってあげられるような動きをするとだいたい喜んでくれていい関係を築けます。
プログラミング経験の少ないメンバーが多いチームでは、オブジェクト指向であったりアプリケーションアーキテクチャの部分を担当したり、 データベースの扱いに長けてないチームではDB設計・構築・管理などを担当します。 モダン開発への理解が乏しいチームでは、スクラム、スプリント、CIなどの基盤を作るサポートをします。 それぞれのチーム・現場で不足していたり、最後の1ピースとなるようなスキルセットで参画すれば 長く良好な関係を築いていくことができます。
僕のことをよく思わない人ももちろんいるし、「いいね！」って言ってくれる人もいます。 「いいね！」って言ってる人の方へ流れていけばとりあえずいい気分で仕事はできます。
同じことをやっても、良い評価をする人も悪い評価をする人もいるので、良い評価をしてくれる場所へ行くのがWin-Winの関係になりやすいですよね。
評価してくれない現場や人たちと一緒に働いてもいいことないですから。
エンジニアリングだけで仕事をするわけじゃありません。 お金を払ってくれる人が喜ぶことをしてあげることがビジネスの基本なので、エンジニアリング意外の部分で何が貢献できるかを考えると良いと思います。
5年後、10年後の自分を想像してそれを実現するために必要なことをトップダウンして、、、っていう自己実現の方法論みたいなものがあるけど、僕にはそんなことできません。
10年前に自分がフリーランスになってると思っていなかったし、主夫とか言っちゃってるとも思っていなかったもの。せいぜい1,2年先くらいまでを想像してその時はこうしたいな、こうなっていたいな、を考えるのが精一杯でその先のことはさっぱりわかりません。
なのでこのエントリーは年始くらいから考えていることを「2年後くらいまではこんな感じで生きていこう」という軸で整理したものです。
僕は主夫なので普段は家事をしながらパートでエンジニアをしています。つまり妻はフルタイムで働いているということです。とても頑張ってくれています。妻が働いてくれている限り飢えてしまうことはありません。なので僕にとっての最も堅実な生存戦略は「妻に働いてもらう」ことなのです。
仕事を続けるには心身共に健康でなければなりません。体の健康を作るには規則正しい生活と食事が重要です。子供は21時には寝かしつけるので、妻にはそのまま一緒に寝てもらいます。そうすれば十分な睡眠時間を確保でき、生活リズムもよくなります。僕の健康のためにもできるだけ全員で一緒に寝るようにします。
でも家族が寝静まった後に飲むお酒はとても美味しい。
毎日の食事を用意するのも主夫の仕事です。食事は肉か魚を主菜し、副菜を野菜中心で2,3品ほどつくります。料理は比較的シンプルなもので煮物、焼物、炒めも、サラダ、和え物にします。 和食を基本にしておけば、だいたいバランスの良い食事になります。和食バンザイ。 手間のかかる料理はあまり作りません。素材の味を活かしましょう。 8割がた妻も子供も食べてくれます。
手のこんだ料理は外食で美味しくいただきましょう。
会社員の労働時間は会社によって設定されます。ゆとりが欲しい時に仕事を減らしたり労働時間を短くしたりすることは簡単ではありません。夫婦ふたりが会社員の場合は1日のほとんどの時間を会社によって拘束されてしまうので、夫婦や家族の時間を作ることは難しくそれがストレスになる場合があります。
そうならないためにはゆとりを持つ必要があります。フリーランスは仕事量を自分で調整できるのであまり働かないという選択肢がとれます。時間的なゆとりを持つことで家族の時間を確保し、ストレスを軽減することができます。
フリーランスとしてやっていくってことは、自分自身が商品になってそれを自分で売る、ということだと思っています。 商品を売る方法はいろいろあります、僕はセールスマンではないから、良い売り方を知りません。 でも商品の売り方に力を注ぐ以前に「良い商品」である必要があることは知っています。 つまり自分の商品価値を高めて「良い商品」になることが大事なのです。
フリーランスの働きなんてのはちっぽけなものなので、大衆受けする必要はありません。 ニッチな分野で自分を売っていくことが大切です。 そのためには自然と希少価値を高めて差別化しよう、という事になります。
特定の技術のエキスパート（専門家）になれればそれが一番良いと思います。 ただエキスパートを目指して勉強してると、本物のエキスパートしか目に入ってこなくなります。 すると、いつまでたってもエキスパートになれる気がしないしいつまでたっても自分が偽物の気がしてなりません。これは精神衛生的に良くないし、自分にはそこまでのストイックさは残念ながらありあません。
なので本物のエキスパートが判別できる程度になれば、ほどほどのスキルを持っていると思われるので、 そういう分野を複数持つことを目指します。 もうそれはエキスパートじゃないんですけどね。
エンジニアは一生勉強が必要だ、と言われています。 しかしみんな勉強しているかというと、実際はそうでもありません。 エンジニアの中でも勉強会などのコミュニティに参加する人はけっして多くありません。 コミュニティに参加する人よりも発表する人のほうが少なく、 発表する人よりもコミュニティを運営する人のほうが多分少ないでしょう。 コミュニティの主催者になることは希少価値を上げる手助けになります。
資格なんて意味ないよ、という意見があります。でも僕はどちらかといえばMatz派です。
「資格試験なんか役に立たない」という偉そうなことが言えるのは、RubyのVMやガベージコレクタは私が書きましたとか、...フレームワークやライブラリのパッチでOSSに日常的に貢献していますというような実績がある人です。 http://bit.ly/favMkT
— Yukihiro Matsumoto (@yukihiro_matz) 2011年3月10日
やはり資格はアウトプットの1つの形として意味がありますし、試験をパスするという一定の能力を示したことになります。 評価する側もわかりやすいと思うので、僕はIPAでやってるいくつかのスペシャリスト資格をとろうと思っています。 合格率も15％くらいなので、複数持っていれば希少価値は高いといえます。
OSS開発に参加してます、というとたいがい「すっげー」となりますしそう思っていました。でも、ホントのところはたいしたことありません。 OSSのコアメンバーでコードにコミットしている人たちはホントのホントに「すっげー」のですけど、もっと簡単にOSS開発には参加できます。 それを知ってからは積極的にプルリク送るようになりました、今後も継続していきたいと思います。
これも希少価値が高く、コスパがとても良いです。
先にも触れているように、生活にゆとりを持つためには仕事を減らす必要があります。 またほどほどのエキスパートになるためにも勉強する時間も確保しなければなりません。 そのためには仕事を減らして時間を作る必要があります。
フルタイム勤務のように週40時間＋αを労働に使っていたら時間なんてあっという間になくなってしまいます。 仕事は週25〜30時間くらいに減らします。
仕事とは別に勉強枠で時間を設定し、その中でインプットとアウトプットを行っていきます。 アウトプットはブログ、勉強会での発表、OSS開発への参加などがありますが、見える形で残すことが大事です。
コミュニティや勉強会に参加してコネを増やします。 発表して注目してもらってコネを増やします。 他になにかあるかなぁ。
別記事で追記しました。
OSSGateワークショップ京都を開催しました。今回も進行役として参加しました。
今回はビギナー、サポーターそれぞれ4人ずつの参加でした。サポーターのうち3人は過去にビギナーとして参加してくれた方々で、大阪メンバーからの助け無しで開催できたので、京都開催としては前進したなぁというところです。 サポーターもビギナーもそれぞれ初めての人が多い会でしたが、1対1で取り組めたおかげか、一緒に困ったり悩んだりしながら、それでも楽しそうに作業に取り組んでいたように思います。
懇親会で「進行役はサポートする人がいれば自分でもやれそう」っていうアンケートの選択肢についての話になり、「結局一人でやらないといけないよね」という意見が出ました。 サポートってなんだろう、みたいな話になって、二人体制でやって足りない部分の説明をもうひとりがやるとか、パートごとに進行役を変えたりすれば負担が減ってできるかも、とかいう意見がでたので次回はそのへんを試してみたいと思います。
進行役は4回目だったので、直近の1週間の間は準備としてOSS Gateワークショップの動画を仕事中に流していました。 スライドは1度だけ通して見て進行のイメトレをやった程度で、今までで一番準備が少ない回でした。
4回目ということで油断したせいか、ワークショップを通してうまく進行ができた手応えがありませんでしたが、アンケートによれば皆さんに満足してもらえたようです。
初めて進行役をやったときの記事を見ると同じように進行に手応えがなくても参加者には満足してもらえていたようなので、このワークショップはパッケージとして良くできているんだと思います。携わっているコミュニティの皆さんのおかげですね。
進行役で参加するとなるとハードルが高そうですが、スライドもしっかりできているしスライドどおりに進めていけばだいたい満足してもらえそうなので、サポーターで参加したことある人は進行役での参加にもチャレンジしてほしいと思います。
そろそろ誰か進行役をやってくれる人が出てきてほしい。 ということで、次回は開催場所の新規開拓と新しい進行役の二本立てのチャンレンジかな。 少しずつではあるけれど京都の人たちが増えてきたので細く長く継続していきたいです。
