(Simple English description follows Japanese) 最近はIMの再ブームやTwitterにより、メールを使う機会は以前より減ったという人は多いのではないでしょうか。また、SPAM等のメールが抱える様々な問題でメールを敬遠する人が増えて、以前よりはメールが担うメッセージ伝達の比重は少なくなりましたが、未だメールはロストテクノロジーになることのない確固たるメッセージツールの一つであることは万人が認めるところでしょう。 Perlでメールを送信する方法はNet::SMTPによるローレベルなものから、今ではスタンダードと言われているEmail::Senderによる方法など、様々な方法があります。このトークでは、制限された開発環境下におかれた場合のいざというときに役に立つレガシーなメール送信手法を振り返りつつ、Email::Senderの使い方をご紹介します。

来年には誕生から10年を迎える Git も、とうとうバージョン 2.0 がリリースされました。 数年前と比較しても、多くの現場で用いられるようになり、それに応じてユーザの数も増えていると思われます。 しかし、 Git はそれまでの主流であった SVN と比べると、考え方、扱い方が難しい部分があり、 必要に迫られて使ってはいるけれど Git をちゃんと使いこなせてはいない、 思わぬトラブルを起こしてしまったことがある、という方も少なくないのではないでしょうか。 便利のために用いているツールがストレスの原因になってしまうことは、喜ばしくありません。 本トークでは、身の回りで起きた Git 関連のトラブルなどを元に、 トラブルの起きにくい Git の使い方 トラブルが起きたときどうするか ストレスを減らしてくれる Git 2.0 の新機能 などについて話したいと思います。 ※ Git の経験を前

(日本語は下にあります / Japanese follows English) We, engineer, live in Terminal. Terminal is our world. We can change our world. We can also change real world from our world. How we can change our world ? Write CLI tool. In this talk, I'm going to talk about what I'm thinking when writing CLI tool. Goal of this talk is to share how to write useful CLI tool from Unix philosophy and my some experiences. In t

tl;dr 初心者が Web エンジニアのコミュニティに触れて感じたこと、また自分が成長するために挑戦しているコミュニティとの付き合い方の話をします。 詳細 インターネット上で簡単にコミュニケーションがとれる昨今、Perl に限らず多くのコミュニティが形成され、YAPC のようなイベントや勉強会が連日数多く開催されています。 このような業界の潮流は他の業界ではなかなか見られない勢いがあり、参加者や業界全体の成長に大きく貢献しているように思います。 そのような世界に憧れて生命科学から情報科学に専攻を変え、今年から Web エンジニアの端くれとして働き始めた駆け出しエンジニアが、これらのコミュニティに実際に参加して感じたことと、自分なりに考える初心者エンジニアの今どきな成長戦略について話そうと思っています。 初心者が技術的な内容で実りのあるトークをするのは難しいかなというのと、せっかくなら初心

PerlBeginnerがMojoliciousで個人レベルでチャットアプリを作りました。 中上級者の突っ込みに期待しつつ、Mojolicious初心者を初級者に導くためにノウハウを発表したいと思います。 7月12日に静岡県三島市で行われる、Mishima.pm#1で発表する内容をさらに洗練して発表したいと思います。 http://atnd.org/events/50401 非同期にコーディングしていますか？ sleepして気づいたMojoliciousはNode.jsと似ているんですね 非同期vs同期でベンチマークを取ってみた Mojoliciousをノンブロッキングなコードにするためには コールバック１つにつきネストがどんどん深くなるんですが・・・ チャットのお話 morboしか動かないんですが・・ Redisの使いどころ MojoliciousからRedisを使うためのモジュール M

仕事でプログラムを書く時は指定された環境や、便利な社内ツール群、相談にのってくれる仲間や、何より豊富なコンピューティングリソースがあるでしょう。 しかし仕事から分離された趣味の開発ではそういったサーバは使えないことがあるわけで、それをどのように調達したり工夫を行うことで、いかに自分のポケットマネーから最大の自己満足感を得られるかを紹介させていただきます。 以下の様な内容を紹介させていただきます。 おすすめのVPS/クラウドサービス　作業用、助っ人、本番用、それぞれの使い分け Amazon EC2/S3 etc, Google Cloud Platform, Digital Ocean, VULTR, さくらのVPS etc... 自宅サーバという選択肢におけるメリット・デメリット 超低消費電力サーバ RaspberryPi で出来る事出来ないこと 作業場という意味での自宅やコワーキングスペ

TL;DR Perlにあまり馴染みのない人に対して真面目なPerlの話をします。最近のPerl事情について知りたい人も対象です 私はこれまで数年間、仕事でガッツリPerlを書いてきましたが、古いPerlにあまり触れて来なかったこともあり、あまりPerlに対する嫌悪感は持ち合わせていません。そして、Perlのエコシステムや、細かいパーツを組み合わせる文化、それゆえに後方互換を大事にする文化などについては非常に好ましいものだと思っています。 Perl界隈は、平均年齢が高めで「成熟した」大人な人間が多いように思います。達人の域に達し、若者からのdisを意に介さない人が多いです。「PerlはPerlで良いものだ」という確信を持ち、それゆえdis合戦に加わることもせず、逆にPerlに拘らない柔軟性も持ち合わせています。そういうPerl界隈の人たちが私は大好きです。 逆に、Perl界隈は歴史がある分、

(日本語は下にあります / Japanese follows English) Hello, every Perl mongers! Do you use Perl::Critic? I think you are using! Yes of cource, Perl::Critic is awesome and powerful tool to check our source code. I wonder how many times Perl::Critic saved me from bugs. But... I feel this module is a bit slowlly, so processing speed becames fast, I thought that I was glad. ...That is where Perl::Lint come in! I i

プログラミングを初めて1.5年、Perlしか触ったことのない若造です。 プログラミングの大部分は 高校の数学科目より単純で、 高校の社会科目より覚えることは少ないはずです。 ですが、多くの人がプログラミングに興味を持ちながら挫折していくのは、 ほとんど全ての入門書がプログラミングを構造化し、それに基づいて説明することをしていないからです。 Perlの要素を構造化し、 Perlを初めて学ぶのに最適な方法として発表します。

日付時刻処理はアプリケーションの根幹を支える重要な処理の1つです。 多言語対応が重要となってきている昨今、タイムゾーンを含め正確に日付時刻処理を行える事が重要となっています。 また、大規模なWebサービスだったりms単位で争う世界になってくると速度も重要になってきます。 本トークでは、今一度日付時刻処理の基本を見つめ直し、ハマりどころや対策をビギナーにも分かりやすく解説します。 また、現時点でearly preview releaseとしてリリースされている次世代日付時刻処理モジュールであるTime::Momentや、Time::Momentやepochベースでの日付時刻処理を支える拙作のTime::Strptimeについても簡単に紹介します。 具体的には以下のような事を解説する予定です。 正確かつ安定した日付時刻処理を行うために気を付ける事 データベースに日付時刻を保存するときの注意点

インフラの自動化、Immutable Infrastructure、新しいアプリケーションのデプロイ方法、Dockerを支えるLinuxのコンテナ技術などなどDockerは各方面でかなり盛り上がっています。先日のDocker Meetup Tokyoにも数百人の参加応募が集まることからも注目の高さがわかります。 ただ、その盛り上がりとは別に、Docker自体リリースされてそれほど長い時間が経っているプロダクトではないことから、どのようにDockerを使ったらよいのか、アプリケーションを動かすベストプラクティスがまだ定まっていないように思えます。 このトークはDockerをまずはとにかく手元や開発サーバで動かして、試して遊んでみようというセッションです。 遊ぶからにはDockerで"Hello World"を出して終りではなく、もう少し便利なこと、例えば身近な作業の自動化やちょっとしたアプリ

tl;dr About my steps from ops to dev engineer. If you're an ops guy who want to be a developer, this will help you somehow. (日本語は下の方です) Details I worked as an ops guy for about four years since I had dropped out from a graduate school. In a last few years, I really felt that I would like to be a software engineer, but I had no chance in my company. So, I decided to prepare for the future chance to

皆さん, チャットツールは使っていますか? Skype, IRC, HipChatなどなど... よくよく考えてみるまでもなく, 日常生活の中で, あるいは仕事の中で, 我々は何かしらのチャットツールを使っているのではないでしょうか. このようなチャットツールの一部では, ユーザが利用するためのAPIを提供しているツールがあります. このAPIを利用すると, プログラムに自動的に発言をさせたり, プログラムが他のユーザの発言に対して自動的にレスポンスを返したり... といった事を実現する, ｢BOT｣と呼ばれるツールを開発することができます. このトークでは, 主にPerl初心者〜中級者で, ｢BOTなんて作ったことないよ!｣といった方を対象に, 様々なチャットツールを対象としたBOTの作り方や, その実用例などを紹介していきます. BOTの開発はプログラミングの学習ネタとして最適ですし,

Ruby は Perl の兄弟/姉妹と呼ばれてから 8年が経過しました. 1 Ruby は 2013 年にリリースされた 2.1 よりバージョンナンバーポリシーが変わり、毎年マイナーバージョンをリリースするという方針に変更になりました。本トークでは Ruby という言語そのものについて仕様策定から、実装、リリースまでの1年間の開発プロセスの実際について紹介します。 また、開発プロセスの途中に多々存在する Ruby にコントリビュートするタイミング、受け入れられやすいコントリビュートの方法、8年前と変わった事、変わらない事についても紹介します。

サービスを提供するシステムがますます複雑化していく昨今、そのための問題解決に用いられるプログラミング言語の選択肢もまた、多様化しています。そのような中で、Perlに関しても私たちひとりひとりのユーザにおいて、その位置付けを見直し続けているという現状ではないでしょうか。 本トークでは、全社的に使用するアクセス解析システムを開発する上で、システムを構成する個別の下位問題がどのような問題であるのかに応じて、Perl, Ruby, PHP, JavaScript, Go, Puppet等、どのようにして適切な言語やツールを選択、使用してきたかを説明します。 その結果として、本トークをお聞きになられたみなさまが、これからのサービス/システム開発における現状と、問題解決のための適切な技術選択とに対する、なにかしらの示唆を得ていただけると幸いです。

私は過去に Test::TCP, Test::SharedFork, Test::Power, Test::Pretty... たくさんのテストを便利にするモジュールを書いてきました。これらのモジュールは Test::Builder の上に構築されております。 我々は、 Test::More 2.0 がでる日を夢見て、ただひたすらに Test::More が出る時代が出る時を待ち続けてきました。 しかし、2014 年にいたり、Test::More 2.0 の開発中止が正式に宣言され、Test::More 2.0 の夢は消え、人々は失意のどん底に打ちのめされております。この暗黒の時代に我々は何をすべきか、それを考え無くてはならないと思います。 そして、今、 Perl5 アプリケーションテスティングを劇的に簡単にするフレームワークが登場しました。その名も Test::Kantan です。非常に