PyCon JP 2018 2018年9月18日(火) 大田区産業プラザ PiO https://pycon.jp/2018/

Gaia is an open source automation platform which makes it easy and fun to build powerful pipelines in any programming language. Based on HashiCorp's go-plugin and gRPC, gaia is efficient, fast, lightweight, and developer friendly. Develop powerful pipelines with the help of SDKs and simply check-in your code into a git repository. Gaia automatically clones your code repository, compiles your code
ドワンゴエンジニアの清水(@meso)です。 去る7/7に、ドワンゴ, ドワンゴモバイル, キテラスのドワンゴグループ3社のエンジニアが集結して、イベントを開催いたしましたので、その様子をご報告いたします。 イベント概要 ドワンゴでは、毎年「エンジニア決起集会」を開催しています。これは、エンジニアが一同に集まって、「よりよいサービスを作りだしていくぞ!」という思いを新たにするという、大規模な飲み会のようなものなのですが、昨年からはより「エンジニア」っぽいイベントをしたいということで半日使っての「ハッカソン」も開催しています。 昨年の様子はこちら 今年も昨年同様にハッカソンを行ったのですが、昨年よりもエンジニアの数が50名以上増えているため、会場がパンクしてしまうのを回避するために、新入社員のチーム開発研修の成果発表会を裏で同時開催することで、何とか全員入れるよう調整しました。 ハッカソンの
今プログラミングを教育に取り組もうという声が高まっています。CODE.orgのようなサイトも立ち上がっていますし、Scratch のような子供から楽しめるビジュアルプログラミングもあります。 デザイナーの中でもプログラミングを始めたい方もいると思います。WWDC 2014 で発表された Swift は、スクリプト言語のような感覚でコードが書けるので、始めるには良い機会なのかもしれません。 ただ、デザイナーの立場からみると、プログラミングは遠い存在に見えることがあります。しかし、「問題解決のため」という視点からみると、デザインとプログラミングには共通点がたくさんあります。人間中心デザインに基づいた発想にも、実装可能なところまで落とし込んで模索しないと、夢心地なアイデアになることがあります(もちろん自由な発想が必要なときもありますが)。コードを書くひとの考え方を取り入れることで、アイデアを洗練
どうもmarcoです。 4/24発売の WEB+DB PRESS Vol.80 を購入しました。 目的は西尾泰和さん執筆の「エンジニアの学び方」の記事を読むためです。 これはエンジニア向けに、どうやって効率的に学習すればいいのかを解説した記事なのですが 元ネタが同執筆者の コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus) 内のコラムが非常に好評で今回記事として書きなおしたそうです。 非常にためになったので触りの部分だけ忘備録も兼ねてご紹介。 知識には3つの軸がある ・広い視野 ・深い理解 ・応用対象 広い視野 学ぶべき対象を見つけるために必要である。 ニュース・ブログ・勉強会等で学ぶことができる。 この軸の学びが足りていないと? 新しいものに気付けず、視野が狭くなり自分の知っているものだけに固執するようになる。 ここで得られる知識は、具
追記: 続編を書きました。マッチョとの戦い 最近、プログラマの生産性が話題です。 いろんな意見があるものの、個人的には 10〜100倍の生産性の違いはあると思います。 いや、それは違う、生産性の高いエンジニアは生産性の低いエンジニアに作れないものが作れるのだからそういう話ではない、という意見もあります。 しかし、実際には生産性の低いエンジニアができもしないことをしようとして結局できないで終わるということがあったりしつつも、何らかの貢献をするというのが普通だと思いますので*1、最終的には 10〜100倍の違いといった形に落とし込めると思います。 で、この生産性の違いはどこから来るのか。 個人的には才能だと思っています。 ぼく自身は、自分のことを中間レベルのエンジニアだと認識しています。 平均の 3〜10 倍できて、トップより 3〜10 倍できないくらい。 でも、自分が平均から抜け出るために何
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
ところでPerlリスクですか。まあ、あるんじゃないですか。ぶっちゃけ。でもさあ、さすがにPerlしか書けない人たちは転職先の選択肢のなさくらい自覚してると思う。なのでPerlがどうとかいう話はしないです。各自でどうぞ。 でね、ポイントはそこじゃないだろうと思うわけですよ。どんな選択をしても同様のリスクはあるんですよ。たとえばMacromedia ShockwaveでLingoで作ってたソフトとかさあ。今ではだれもメンテできないでしょう? だから今隆盛をきわめてる技術で作ったものが、何年か後にリスクになるってのは、それはそういうものなんですよ。べつにPerlに限らん。Perlはたまたま今そういうフェーズってだけで、明日は我が身ですよ。hamlとかsassとか。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く