読者です 読者をやめる 読者になる 読者になる

hariport

haripo.com

Grand Frontend Osaka 2016 行ってきた

kfug.jp

ひさしぶりにイベントに行ってきた。

概要

2日間開催のイベントで、1日目はハッカソン企画 "Try Tech Kansai"、2日目はセミナーとLT大会の構成。 ハッカソン企画 Try Tech Kansai はテーマが「あなたにとってはじめての技術体験」ということで、 いくつかの技術でブース出展されている中から新しいものに触れてみようというハッカソン。 Angular 2 や Vue 2.0 など新しいフレームワークもあって魅力的でしたが、 今回は D3.js に取り組むことにしました。 ビジュアライゼーションは研究と相性いいですし、いつかやろうと思っていたのでちょうどいい機会でした。

ハッカソン

エンジニアのスキル可視化っぽいことができないかと思って、 プログラミング言語地図というのをつくりました。 GitHub から言語利用データを持ってきて、 似た言語が近い位置に、似てない言語が遠い位置にくるように平面上にマッピングします。 マッピングした平面上を指差して「このへんのスキルがあります」みたいなことが言えたら面白いなあと。 技術的には、GitHub からレポジトリの言語別 bytes 数を取ってきて user-language 行列に落とし込み、 PCA 前処理からの t-SNE で 2次元マッピングです。

で、できたのがこれ。

f:id:harip0:20160829134130p:plain

なんとなく「地方感」がでていませんでしょうか。

もちろん解釈不可能な部分も多いですが......

この地図上に私の GitHub アカウントを可視化したのがこれ。

f:id:harip0:20160829134504p:plain

JavaScript, C++, C# と Julia が濃い白(GitHub 上のコード量が多い)になってますね。 全体的にフロントエンド周りと C#, あと Lisp と Julia をよく書いていることがわかります。

と言いたいところですが、 Lisp はほぼ Emacs の設定ファイルで Julia も本家 Julia のレポジトリを Fork しているに過ぎず、 精度についてはなかなか難しいものがあります。 FortranMatlab も多分 Julia レポジトリに入ってるんでしょう(書いたことない)。 さらには、(node_modulesのような)依存パッケージなどを無視することが GitHub API の仕様上できないので、 フロントエンド慣れてない人が node_modules をレポジトリに含めたまま GitHub に置くと、 地図上ではフロントエンドスキルのある人に見えてしまいます。

言語の特性を可視化するという点ではうまく行ったのではないかと思いますが、 エンジニアスキルの可視化という点では厳しい結果です。

もっとインタラクティブにしたりデザインにこだわったりしたかったですが、 いかんせんデータ解析的な処理に時間がかかったり、 D3.js の世界観に馴染めず苦労したりでうまくいきませんでした。

セミナー

2 日目のセミナーについて。 午前に外せない予定ができてしまい途中参加になりましたが、面白かった。

フロントエンジニアの未来像について、 「データフローの適切な扱い」ができることが重要になってくる、 ただ JavaScript をコーディングするだけがフロントエンドではなくなったんだ、というプレゼンがありました。 本イベントのなかでもサーバレスや WP-API など、フロントエンドの構成要素として選択肢が増えていることを感じましたし、 JavaScript ですら TypeScript や Babel、さらには WebAssembly で置き換えられる時代が近づいています。 いかに要素を選択するか、いかにデータフローを構築するか、は難しさを増しそうです。

一方で、変態的 CSS テクニックや HTML メールなど技術を問われる場面もあることがわかりました :innocent:

おわりに

開催日前後で忙しくなってしまいキャンセルしようかと悩みましたが、行ってよかったです。 ありがとうございました。

英語について

英語を頑張ろうというポストです。

Why

最近 GitHub で公開していたライブラリに外国の方から Pull Request が来ました。 ちゃんとドキュメント作って公開しておけば誰かが見つけて使ってくれるんですね。 頑張って英語で書いた甲斐がありました。

規模が全く違いますがこういう話です。

note.mu

私みたいなデベロッパにでも PR がやってくる可能性があるのですから、 英語で書くのは大事です。

で、丁寧にメッセージを添えてくれた("Great library btw!" とまで書いてくれていた) Pull Request に対して気合いを入れて感謝を述べたかったのですが、 英語のメッセージ作法がよくわからず自信が持てなかったので "Thank you!" とだけ送って merge しました。 これがちょっと残念で、現在の英語を頑張りたいモチベーションになっています。

他には

  • 海外の Tech 系 Podcast が聞けるようになりたい。
  • 海外の MOOC を受講したい
  • リファレンス・論文をさくさく読みたい

などいろいろ思うところがあります。

How

春頃に「英語で読む村上春樹」を読んでいたんですが最近は読めていなかったので、 これをやります。

www.nhk-book.co.jp

英語と日本語を比較しながらその作品を精読します。言語や文化の違いはもちろん、作品にこめられた隠されたメッセージを発見していきます。

これ本当に精読していて、日本語の部分だけ読んでも面白いのでおすすめです。

英語学習としては音読を中心に、ラジオで発音を確認しながらやっていきます。 英語を速く発話出来るようになればなるほどリスニングが強くなるという話もありますし、 使える語彙を増やしていきたいと思っています(使える語彙と読める語彙を区別して言う言葉ってなんでしたっけ)。

なぜ HSP では関数を使わないのか

HSP、ご存知ですか。

HSPTV!

Hot Soup Processor と呼ばれるゲーム制作に特化したプログラミング言語です。 なんと開発セットに公式エディタまで付属しており、簡易にゲームを作ることができます。 小学生向けの入門書が売ってるレベル。 私も小学生のころに HSP に触れてプログラミングの世界に入門しました。

さて、かねてより HSP にまつわる疑問として 「なぜ HSP では関数を使わないのか」というのがありました。 HSP では基本的にサブルーチンを使います。

gosub *sub // call subroutine

*sub
   // something
   return

こんな感じです。 gosub 命令によって指定されたラベル *sub に処理がジャンプし、 return命令によってサブルーチンから呼び出し元にジャンプする。 ここには引数も変数スコープもありません。基本的に HSP の変数はすべてグローバルです。

一方で関数はないのかというと、もちろん HSP において関数を定義することが可能で、 これはローカルスコープもあり引数も取れます。 なぜ関数を使わないのか。 小学生当時は疑問に思いませんでしたが、関数の様々なメリットを理解して以降、 なぜそのプログラミングスタイルが推奨されているのか、意味が分かりませんでした。

しかし最近になってようやく気づいたのですが、 この疑問の答えはおそらく、「関数は難しい」からなのだと思います。

関数はなぜ難しいか。 まず、関数はいくつかの機能の複合だからです。

  1. 処理順を変える
  2. スコープを作る
  3. 引数をコピーする
  4. 戻り値を返す

関数を理解するためには、「スコープとはなにか」、 「引数とはなにか」を理解せなばなりません。 これらを天下り的に教えたとして、 「なぜグローバル変数で受け渡さないのか」、 「スコープを作るメリットはなにか」を曖昧なままに コーディングを進めると、結局は関数のメリットが生きない、 サブルーチンと同じような関数を書いてしまうでしょう。 コーディング経験の浅い小学生にこれを理解させるのは難しいと思います。

もうひとつ、関数が難しいのは、同じ関数が宣言、呼び出し、定義の 3 通りの記法で現れる点です。

// 宣言
int func(int);

int main() {
  // 呼び出し
  a = func(3);
} 

// 定義
int func(int v) {
  return v;
}

これは C 言語っぽい記法ですが、それぞれで必要なものが異なっています。 宣言には戻り値の型と引数の型が必要ですが、呼び出しには不要です。 定義には引数名が必要ですが、宣言と呼び出しには不要です。 そして宣言と定義には左辺値は書けません......。

理解してしまえば簡単ですが、人によってはこのあたりは混乱します。 本当に混乱するんですよ。a = func(int 3); とか書いたり......。

さて、ここで HSP のサブルーチンを思い出しましょう。

gosub *sub

*sub
   // something
   return

サブルーチンは「処理順を変える」以外の機能を持たず、 さらに引数も戻り値もないため記法も簡易です。 プログラミング初心者に対象を絞ったがゆえの潔さがあります。 迷いようがありません。最高。

というわけで、最近気づいた「なぜ HSP では関数を使わないか」でした。 HSP すごい、よく練られた言語だったんだな。

JXUGC Xamarin ハンズオン復習

jxug.connpass.com

JXUGC Xamarin ハンズオン大阪に参加してきました。

MonoGame で Android ゲーム開発をやってたのでその恩恵には授かっていましたが、 いままで直接 Xamarin に触れて開発したことはありませんでした。 料金体系が変わり卒業後も無料で使えるようなので、ここらで一度試してみようかと。

ハンズオンの内容としては Xamarin ネイティブ / Xamarin.Forms それぞれのアプリ開発の一歩目って感じでした。 コントロールの配置やイベント処理、 Intent の呼び出しなど。 簡単なアプリの開発に踏み出せるだけの知識が整ったので、 忘れないうちにもうひとつ何か作ってみよう、ということで、RSS リーダもどきを作りました。

github.com

更新機能もなければ新たに RSS を登録することもできません。 現状 ytabuchi さんのブログ(http://ytabuchi.hatenablog.com/)の更新情報しか見れません。 フィードを取得してリスト表示し、タップされた項目をブラウザで表示するだけのやつです。

f:id:harip0:20160424011414p:plain:w300

今日だけで Xamarin での開発の大枠をつかんで、ここまで出来るようになりました。 勉強会の主催および参加者の皆さま、ありがとうございました、ハンズオン楽しかったです!

f:id:harip0:20160424013059p:plain:w300

インターン行った

インターンシップの Data Analyst コースに参加しました。

密度高く学んだ 2 週間だった。

学び1. データ解析とはなにか

いままで研究室でやってたことはデータ解析じゃなくて機械学習だったのか!って気づきました。 ちゃんと基礎統計しっかりやって変数選択したりモデル構築したりする意識が完全に欠けていた。

学び2. 解析ツール・言語の強さ

基本的に C++Ruby でプログラムを書くことが多く、Python, R には苦手意識がありました。 というか自分で手法を実装してなんぼのもんやろといった気持ちがあったのですが、 データ解析の現場において R を使いこなす人の強さには舌を巻かざるを得なかったです。 ライブラリ資源が揃ってる言語はやはり便利でした。

言語以外でも今回 Jupyter (iPython notebook) とか scikit-learn も初めて使いましたし、 Tableau も初耳でした。 Tableau を使いこなして基礎集計をばんばんやっていくのすごかった(こなみ)。

学び3. 開発スキルの使い道

web 開発でアルバイトをしていることもあって、 データ解析で web 開発のスキルが役に立てられないかと考えていましたが、 web フロントエンドの知識でも解析の現場で有用だということが分かりました。 たとえばデータの可視化を試みた時に、 d3.js を扱うことができればインタラクティブな ビジュアライズができるようになります。

以上、学んだことを簡単にまとめました。 本当はもっと多くのことを学びましたし、 それ以上にデータ解析の楽しさや苦しさ、チームやメンターの方々に対する感謝反省など書くべきことはたくさんありますが、 インターンを終えて早くも半月が経ってしまいましたし、このへんにしときます。

DDPC 2016 に雑魚ながら参加した

先月 AtCoder にて開催された DDPC (DISCO presents ディスカバリーチャンネルプログラミングコンテスト 2016) のオンサイト予選に出場し、 雑魚い結果を残したのですが、後日なぜか本戦参加のメール連絡が来ました。 勉強会とかハッカソンはたまに参加しますが競プロのイベントは経験がなく、 せっかくの機会なので初心者ながら出場してみました。

コンテスト

雑魚なので結果は普通に最下位近くでした。 Bの部分点は取りたかったのですが 必要なテストケースのうち1つだけWAがあって、その原因が究明できず。 なにが間違っているのか、時間に余裕ができたら調べたい。

コンテストをオンサイトでやる意味はルール違反がしにくいとか、運営的なメリットの点でしょうか。 競技プログラミングの楽しさとか、そういった面でのオンサイトの魅力はあまり感じられませんでした。 もっと競プロが上達すればまた違うかもしれません。

コンテスト以外

これが意外と楽しかった。

落合先生の公演

DISCO はシリコン加工技術の会社で、もともと競技プログラミングとの関連も薄い分野です。 なので chokudai さんが Twitter で言及された通り、 競技プログラマと DISCO の方々の両方を相手にした公演って難しいと思うのですが、 そこでに面白い内容が作れるのが凄い。 競技プログラミングが半導体加工にどう生きるのか、納得出来ました。 あとスライドにペンツールで書き込みながら話すプレゼンが面白かった。

DISCO 社内見学

工場見学って感じでかなり楽しめました。 いままでずっと IT 業界しか見てこなかったので、 でかい加工機とか紙より薄いブレード、超微小の加工技術について見学して、 別の業界でのプログラマとしての働き方を考えるのは新鮮でした。 たとえば、カスタマーの要望した素材で実際にカッティングの実験をする役割の職員が 「アプリケーションエンジニア」と呼ばれているなど、文化の差を感じます。

DISCO社 の製品はユーザの目に触れることのない、製品の内側を支える裏方です。 いままでは「裏方であること」に求心力を見い出せていなかったのですが、 多くの人が使う部品を作るという面で半導体や加工機械の与える影響は計り知れず、 魅力を感じました。

今後

蟻本やるぞ!

Thinking, Fast and Slow

A 君はアニメ・ラノベを愛するオタクで日本橋によく行きます。A 君の説明として最も可能性が高そうなものを選んでください:

  1. 工学部所属の大学生である
  2. 山岳部に所属していて交友関係が広い
  3. 工学部に所属していて服装に無頓着だ
  4. 社会学専攻の大学院生である
続きを読む