すぎゃーん タイパや効率が最優先されがちな現代ですが、あえて正解までの最短コースだけを目指さず、道のりそのものを味わうプログラミングの楽しみ方を探求し、共有します。
題材の一つとして、毎年12月に小さなパズル問題が毎日出題される「Advent of Code」を紹介します。同じ問題に対しても解法は無数にあり、用いるプログラミング言語もアルゴリズムも様々、まさにTMTOWTDI! 素朴にコードを書いて正解を導出して終わりにするのではなく、美しく効率的なコードを目指してみたり、業務では絶対に書かないような難解で突飛なものを考えたり、色々な楽しみ方があります。正解とは関係なくパズル入力の可視化に注力している参加者もいて、他の人の取り組みを見るだけでも学びがあり、とても面白く刺激的です。
また、私は個人の趣味活動としても「Pentomino」や「だんご屋のひまつぶし」といったパズルを自ら題材として取り上げ、プログラムで解く取り組みをしてきました。効率的な解法を調査し検証し、また得られた解をWebブラウザ上でインタラクティブに可視化するなど、自分なりのこだわりを持ったやり方で楽しみました。正解だけを求めて一直線で終わらせないからこそ得られた経験や学びを紹介します。
「コードはAIに書かせるもの」になりつつある現在ですが、やっぱり自分でコードを書くのは楽しいものです。自分流のプログラミングの楽しみ方を広げるためのヒントを持ち帰っていただき、“自分も何かやってみよう”という最初の一歩を後押ししたいと思います。
近藤うちお このライトニングトークは、Perlの「バイナリデータの操作」という、一見地味な機能に焦点を当てます。
Perlは、その起源から「テキストもバイナリもバイト列」として柔軟に扱う文化を持ち、古くからバイナリ操作の領域で信頼されてきました。その中でも特に重要な pack / unpack 関数は、ソースコードを辿ると1989年リリースのPerl 3.0で登場したそうです。以来、 pack / unpack の強力な機能を駆使することは、バイナリハックの基本的技術と見做されてきました(要出典)。
また、Perlの pack / unpack は他の言語実装にも影響を与えました。Rubyの場合は Array#pack と String#unpack というメソッドとしてポートされ、なんとバージョン1.0より前の段階(当時のChangeLogによると1994年)から実装されています。そしてこちらも多くのRubyプログラムで利用されています。 もちろんPythonやPHPにも同名の関数が存在します。 pack / unpack というニッチな機能で色々な言語が繋がっているのは興味深くありませんか?
ということでこのトークではそんな魅力的な pack / unpack 関数について、Rubyistの立場から、後輩であるRubyの Array#pack / String#unpack と比較しつつ解説します。多面的に pack / unpack を理解することで、「バイナリパック」の世界に足を踏み入れましょう!
hkoba Perl でモジュールを開発するとき、書いたメソッドをさっと試したくなって、コマンド行で↓このようなワンライナーを書いた経験はないでしょうか?
perl -I$PWD/lib -le 'use MyClass; use Data::Dumper; print Dumper(MyClass->new(foo => [3,4,5])->bar({baz => 8}))'
これがもし、↓このように書くだけで試せたら、便利だと思いませんか?
./lib/MyClass.pm --foo='[3,4,5]' bar '{"baz": 8}'
更にもし、↑ --foo の attribute 名や bar のメソッド名にコマンド行補完が効けば、色々と捗りそうだと思いませんか?
この LT では、これを可能にするためのモジュール MouseX::OO_Modulino と Zsh の補完ヘルパー App::oo_modulino_zsh_completion_helper についてご紹介させてください。
iberianpig Rubyで「Fusuma」というLinux向けマルチタッチジェスチャのユーティリティを開発し、3000超のGitHub Starsを獲得しました。
「Macみたいにシャッとスワイプしたい」という思いつきから、12年前に初めて書いたものが「xSwipe」という200行のPerlスクリプトでした。
ログを出力してパースして、キーエミュレーションのコマンドを呼ぶ、たったそれだけだったのですがGitHubに上げたところ、思いがけず多くの反響をもらいました。
“自分が欲しいものを自分で作る”の原体験はPerlにあることを思い出し、当時書いたコードや今のFusumaと見比べてみます。
松木 雅幸 / Songmu ghqは複数のソースコードリポジトリを統一的なルールでローカルマシンに配置してくれるコマンドラインツールで多くの開発者に利用されています。単純なアイデアのツールではありますが、その分とても強力です。全てを ghq get することで、リポジトリをどこにcloneしたか見失ってしまうことが無くなります。
リリースから10年以上経ちますが、長年、ghqが何の略なのかは謎とされてきました。今回、YAPC::Fukuokaのテーマの「Q」にちなみ、その開発のルーツからひも解き、その秘密に迫っていきたいと思います。
ghq が go get にインスパイアされて作られたこと、実はGit以外の数多くのバージョン管理ツールにも対応していことなどについてお話します。またghqが対応しているバージョン管理ツールを全て挙げ、それらの特色についても説明します。世の中にはGit以外のバージョン管理ツールがまだまだ活発に使われていることを皆さんは知ることができるでしょう。
倉井龍太郎 Japan Traditional Company(JTC)という揶揄は好きではないけれど、伝統的日本企業であるサンリオでソフトウェア開発部門の立ち上げを担当しているkurainです。
みなさんご存知のようにソフトウェア開発は、技術選定・納期設計・品質保証・UI/UX・スケール運用など多くの判断が絡む専門的技能です。
内製経験のない組織では、その難しさの前に外注設計やコミュニケーションの段階からつまずきがち。
そのような中で開発組織を立ち上げてみると、自分が“当たり前”だと思っていたソフトウェア開発のための知識や習慣が、大いに役立つことがわかってきました。
そして、現職では内製開発も外注開発も並行して行っていますが、どちらも伝統企業ならではの様々な困難があります。
その困難にも正当な理由はあるわけで、どうにか困難を乗り越えながら楽しい開発組織を作るべく日々奮闘しています。
このLTでは、伝統企業あるあるを紹介しつつ、
①JTCでエンジニアが今こそ必要とされる背景、②立ち上げ初期に直面した伝統企業ならではの困難、③そしてこの環境で働くことの楽しさ——を5分に凝縮してお届けします。
伝統企業で一緒に「無双」しませんか?