プログラミング言語Pythonの生みの親がDropboxを退社、Dropboxが語る一流プログラマーの姿とは？
by Sagaru9535 プログラミング言語Pythonの生みの親であるグイド・ヴァンロッサム氏は、2018年7月12日に突如Python開発のBenevolent Dictator For Life(BDFL、優しい終身の独裁者)を退き、Pythonの仕様策定から離れる意向を示しました。そんなヴァンロッサム氏は2013年1月からDropboxの主任エンジニアを務めていましたが、2019年10月29日時点で既にDropboxを退社していることをDropboxの開発チームが公表。公式ブログでヴァンロッサム氏のエピソードと共に謝意が述べられています。 Thank you, Guido | Dropbox Blog https://blog.dropbox.com/topics/company/thank-you--guido ヴァンロッサム氏はアムステルダム大学で数学と計算機科学の修士号を取
Thank you, Guido
open search After six and a half years, Guido van Rossum, the creator of Python, is leaving Dropbox and heading into retirement. From the beginning, we knew Guido would be a great addition to our company. In fact, his contributions to Dropbox date back to day one. Our CEO Drew Houston’s very first lines of code for Dropbox were written in Python. “What I love about Python is it just works,” says H
日本企業にも「オープンソースプログラムオフィス」が必要、「企業のためのオープンソースガイド」が公開
オープンソースソフトウェア（OSS）の統括・推進団体であるLinux Foundationの日本支部、Linux Foundation Japanが、約1年がかりで翻訳を進めてきた「Open Source Guide for Enterprises」の日本語版、「企業のためのオープンソースガイド」をWebで公開した。 これは、一般企業におけるOSSの活用・推進に関する指針やベストプラクティスを、多角的に提示したもの。Linux Foundation日本担当バイスプレジデントの福安徳晃氏は、次のように話す。 「テクノロジー企業、一般企業を問わず、多くの企業の現場でOSSが利用されている。現場任せではなく、組織全体としての利用管理を進めるべき段階に来ている企業は、日本でも増えている。また、例えば自動車メーカーに見られるように、事業戦略の一環として、社内で開発したソフトウェアをOSS化して推進し
XP祭り2019 B-6 アジャイルソフトウェア開発への統計的品質管理の応用
English Version： https://www.slideshare.net/sakataakinori/xp-fes-2019-b6-application-of-statistical-quality-control-to-agile-software-development XP祭り2019 B-6 「アジャイルソフトウェア開発への統計的品質管理の応用」の資料です。 On 2019年8月20日, in XP祭り2019, XP祭り2019セッション 【セッション情報】 セッションID：B-6 時間：14:45～15:15（30分） 会場：B（1F 102室・後） タイプ：講演 【セッション内容】 アジャイル開発のマネージメントやチーム運営のお手伝いをしていく中で、ウォータフォールで使われている品質メトリクスを利用しようとしているプロジェクトを見かけることがあります。 ウォー
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
44 engineering management lessons
I now write regularly at www.spakhm.com. Everything new is there! Welcome to engineering management. It’s fun, it’s exhausting, it’s rewarding — but most importantly it’s new! What worked for you before won’t work now. You’ll have to acquire a new set of skills, and shed some bad habits in the process. Here is a short guide to get you started. Do Attract, nurture, coach, and retain talent. Talk to
限られた裁量の中で新規プロダクトを最短リリースした、という話 | アピール | 未来の教育を作る人のマガジン
Mobile Developer｜羽田 健太郎 新卒でヤフー株式会社に入社し、インフラのオペレーション改善や、iOSアプリ開発に従事。プライベートではハッカソンに参加したり、Go言語でWebサービス開発をしているマルチプレイヤー。2016年RareJobで唯一のMobile Developerとして入社し、ネイティブアプリケーション(iOS/Android)を担当。WebRTC技術を活用したサービス化のエンジニア責任者として、日本フィリピンを横断し、ブロダクト企画から開発、運用まで担っている。 降って湧いた大きな裁量 「羽田くん、Skypeなくしてよ」 月一の上長とのMTGでなんとなく言われたその一言。 しかも「プロジェクト化は、今のとこないんだけど。」と仰る。え？1人？？？ 最初はとんちかと思って、 「iPhoneで屏風にskype出してVRでなんとかするアプリ」を作ろうと思っていたが、
モブプログラミングとコードレビュー
特集1では，2人1組になってコードを書くペアプログラミング（ペアプロ）と，チーム一丸となってコードを書くモブプログラミング（モブプロ）について解説します。… この中で、モブプロは モブプログラミングの「モブ」とは群衆のことです。モブプログラミングでは、ペア（2人）ではなく、モブ（チーム全体）でプログラミングを行います。モブの人数は3人から5人くらいを想定しています。ペアプログラミングと同様に、コードを書くだけでなく、すべてをモブで行います。 と説明されています。 私がモブプログラミングという言葉を初めて聞いたのは、現マイクロソフト牛尾氏の以下のブログ投稿だったように思います。
スタートアップの現場で役立つ開発要件のまとめ方
こんにちは。ハウスマートの高松(@t2kmt)です。 皆さんは開発要件をまとめるのにどんなフォーマットを使っていますか？ 開発要件をいい感じにまとめるのって大変ですよね。 ドキュメント整備せずに開発に着手し始めてしまうと手戻り抜け漏れが出てしまいますが、一方で要件定義書をガチガチなフォーマットにするとドキュメントの作成自体の工数が増えてしまいます。 スタートアップはスピードが命。ドキュメントを書きまくって開発が進まないなんて言語道断です。 開発要件の整理はプロジェクトの成否に多大なインパクトを与えますが、ほとんどの現場では企画を考える人にフォーマットが委ねられていることが多いと思います。 今回は皆さんが快適に開発要件をまとめられるように、ハウスマートで利用している mini spec というフォーマットをご紹介します。 mini spec とは mini spec とは開発の要件をまとめる
自立自走型チームの構築と心理的安全性を高める施策 - Qiita
はじめに ※大層なタイトル書いてるけどただの日記みたいなもんです ※あくまで個人の見解であり、所属する団体・組織の見解ではありません 現在自分は客先常駐型でエンジニアの派遣を行う事業をメインとする会社で、小規模ながら社内で受託開発を行う部署に在籍している。その組織の仕組みは「プロジェクトマネージャー」と「組織の管理職という肩書としてのマネージャー」が兼任になることが（自分も含め）ほとんどだった。なんでもできるマネージャーがタスクを分解、できそうなメンバーにアサインし、メンバーはタスクをこなすのみに注力という構図で、以下のような問題が起こっていた。 マネージャーが非常に多忙でSPOFになるケースが多々。とてもじゃないが休めない できる人のみにタスクが集中し、できない人は本当に何もしてない メンバー間での責任の押し付け合い マネージャーからメンバーに対する高い圧力 やる気があるメンバーのモチベ
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
「ソフトウェア開発データが語るメッセージ2017」を公開～ソフトウェアの信頼性は向上するも生産性は低下傾向～：IPA 独立行政法人 情報処理推進機構
概要 独立行政法人情報処理推進機構ソフトウェア高信頼化センター（以下、IPA/SEC）は2018年3月6日、「ソフトウェア開発データが語るメッセージ2017」（以下、本書）を公開しました。 本書は、「ソフトウェア開発データ白書2018-2019」（2018年10月発行予定）作成用に収集した最新のプロジェクトデータに基づいて、ソフトウェア開発の傾向を分析したものです。 分析の結果、ソフトウェア開発の信頼性は向上しているものの、ソフトウェアの品質に対する要求の高まりにより、生産性は低下傾向にあることが分かりました。また、生産性・信頼性の向上には定量的管理を推進し、品質要求レベルに見合った生産性目標を設定すべきこと、さらに、要員の人材育成が重要であることが分かりました。 背景と目的 近年、ソフトウェアの大規模化／複雑化が進む一方、信頼性向上、生産性向上、開発期間短縮等の要求は高まっています。この
選定した技術が1年で死んだ話 | そど
今年の夏頃から、特にサービスとして出すわけではなく、社内で使っているシステムのリプレースを行う事になりました。主な目的はレガシーすぎる設計をある低度モダンにする事、そして他のシステムと連携出来るようにする事、です。 対象のシステム 見積書や請求書などを管理・発行している。機能はそれなりに多いがUI操作はFormベース、テーブルタグで諸情報を表示するシンプルな物。ノンフレームワークで1画面1PHPファイルな古き良き時代のコード。おそらく10年ぐらい？稼働している。当初はPHP 5.1、PostgreSQL 8.x系だったが、現在はPHP 5.6とPostgreSQL 9.6で稼働しています。 その他の社内システム かつてはノンフレームワークだったり、太古のバージョンのCakePHPだったり、PHPが4系だったりしたが、概ねCodeIgniter 3系最新版 + PHP 5.6～7.1 + P
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
「社内横断の技術組織を終わらせました」から8カ月。あの経験から見えた「組織課題の解決法」と「無価値にならないエンジニア」の条件 - GeekOutコラム
「社内横断の技術組織を終わらせました」 こんな告白エントリーに見覚えのある方もいるのではないでしょうか。 このエントリーの主は、サイバーエージェント子会社のCyberZ所属で、国内No.1スマホマーケティングツール「F.O.X」サービスマネージャーの門田矩明さんです。 門田さんは、2017年の1月にこのようなエントリーも書いています。 ■CyberZ全社横断の技術組織「技術戦略室」はじめました 残念ながらこの技術組織は3カ月ほどで解散してしまいますが、その後に書いた「記録」としてのエントリーが多くの人の心に響き、広がっていきました。しかし、この後どうなったのかについては、あまり語られていないように感じられます。 そこで、今回は門田さんへ「横断組織が終わった後」について、お話しいただきました。 インタビューの中で見えてきたのは、自身の経験を踏まえたうえで門田さんなりに考えた「横断組織論」、そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Shopifyはいかにしてモジュラモノリスへ移行したか
企業のためのオープンソース ガイド – The Linux Foundation
EclipseとOracle、javaxパッケージ名前空間と商標の扱いに関する合意を断念
プロジェクトをリードする技術 / Project Leading is Skill
正しく失敗しながら進むプロダクト開発/railsdm2018
