タグ

programmerに関するruedapのブックマーク (81)

  • K のこと -- steps to phantasien t(2007-11-03)

    友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも

  • Stack Overflow Developer Survey 2015

    Overview Every year we run a survey. This year, more developers answered more questions than ever before. 26,086 people from 157 countries participated in our 45-question survey. 6,800 identified as full-stack developers, 1,900 as mobile developers, 1,200 as front-end developers, 2 as farmers, and 12,000 as something else. We conducted this survey to help us better understand our community and to

  • チーム開発とクソコード - tototoshi の日記

    今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく

    チーム開発とクソコード - tototoshi の日記
  • 良いProduct Managerと良いTech Lead - ワザノバ | wazanova

    http://engineering.foursquare.com/2014/01/30/good-tech-lead-bad-tech-lead/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 A16ZのBen Horowitzが、1996年にNetscapeのDirector of Product Managementだったころに、「Good Product Manager, Bad Product Manager」という名エントリーを残しています。また、これに倣って、FoursquareのJason Liszkaが、「Good Tech Lead, Bad Tech Lead」をまとめています。 自分達のあるべき姿を律するため、かつ、悪い手にならないようにという自戒の意味をこめて、気に入った

  • 帰りの機内で観た映画2本 - ただのにっき(2013-08-06)

    ■ Team Geek ―Googleのギークたちはいかにしてチームを作るのか(Brian W. Fitzpatrick) だいぶ前にオライリーから献していただいたのだが、紙だったのでどうしようかなーと思っていたらすぐに電子版が出るという噂を聞き、待っていたらアメリカ出張中に送ってくれたのだった。おかげで帰りの飛行機で読めました*1。電子書籍バンザーイ。 とはいうものの、実は書に対しては(悪い)先入観がある。事前にartonさんの評を読んでざわっときたのだ。書を開いたら冒頭に「ミッションステートメント」が出てきてそれは疑惑に変わり、さらに文中に「信頼残高」の用語が出てきて確信した。このの著者、フランクリン・プランナーやってるだろ! 文献の中に「7つの習慣」が出てこないのが不思議なくらいだよ。 10年も前の話だが、会社でフランクリン・プランナーのセミナーを受けさせられて、あの考え方に

  • 『Team Geek』が面白い

    Team Geek ―Googleのギークたちはいかにしてチームを作るのか さっそく『Team Geek』読みました。200ページ程度と分量が多くなく、わりと気楽にさっくり読めます。しかしこれは面白い。 ソフトウェア開発のチームやプロジェクトなどの運営にかかわるもろもろのエッセイ集、みたいなノリの。内容はコーディングや実際の開発の細部には立ち入らず、むしろエンジニア同士の(あるいはエンジニアとエンドユーザの)関係のような「人間」にフォーカスを当てている。 いわく、ソフトウェア開発というのはチームプレイである。孤高の天才がひとりで作るようなモンじゃない。ユーザ=自分みたいなソフトウェアなら別だけれど、世間に広く使われるようなものというのは、一人で作るということはほぼないんじゃないかと思う。だから、個人個人の技量(技術力)とべつに、チームプレイをどうこなすか、という視点がないとうまくまわらな

    『Team Geek』が面白い
  • おそるべきTeam Geek - L'eclat des jours(2013-07-21)

    _ おそるべきTeam Geek 角さんとオライリーからTeam Geekを頂いたので、読んだ。完読した。これはひどい。おもしろいし、おそらくとても役に立つから、みんな、読め。 Team Geekを一言で説明すると『Googleに勤務する中堅エンジニアがOSSのプロジェクトGoogle含む企業で遭遇した経験を元に解説する成功するチーム作り』なのだが、おそらく、その言葉から推測される内容とは全然異なるものが読める。 ここで読める(学べる)のは、(書と同様に虚飾を取っ払った率直な書き方をすれば)どうやって自分が組織の中で成功するかについての技術だ。 中核をなす技術は、HRT(謙虚、尊敬、信頼)であり、それに基づいた行動規範が導かれ、その規範にしたがってどうすれば良いかについてケースとそれに対するアンチパターンや成功事例を示す。謙虚、尊敬、信頼! ってまるで根性、友情、勝利みたいに、正義そ

  • Incidents (「代表的プロダクト」について)

    ひとくちに「Webエンジニア」といってもその内実は様々だし、得意分野や成果の出し方も違う。ここではそのような多種多様のいずれが良いとか悪いとかそうしたことをいいたいのではないということをあらかじめ注記しておく。 職業生活において成果を充分に挙げている(あるいは挙げようと努めている)ことは前提として、組織上公式にプライベートな時間(要するに業務時間外)における技術的活動について、組織の外部との接点のある場所で活動することを好むひともいれば、あくまでも職業生活の糧となる活動に重きを置く(つまり寝ても冷めても仕事のことを考えているような)ひともいるだろう。 前者はOSSに深くコミットするだろうし、後者は組織の成果を直接に志向するだろう。そのいずれにしても、プライベートな時間における技術的活動が、エンジニアの成長にとって大きな糧になり、そのことが所属する組織における成果につながることは、普通にあり

  • Teach Yourself Programming in Ten Years 日本語訳

    以下の文章は、Peter Norvig による Teach Yourself Programming in Ten Years の日語訳である。 翻訳文書については、以下の方々にご教示を頂きました。ありがとうございました。 Shiro Kawai さん:誤訳の訂正 三好博之さん:誤訳の訂正 竹中明夫さん:2001年7月改版分の訳、誤訳の訂正(共訳者にクレジット) Toshihiko Ono さん:誤訳の訂正 アクビさん:訳注3に関する情報 どうしてみんなそんなに急ぐの? どの屋に足を運んでも、『7日で学ぶ Java』といったハウツーを見かけるし、そのそばには Visual Basic や Windows やインターネットなどについて、同じように数日や数時間で学べると売りこむが無限のバリエーションで並んでいる。Amazon.com で以下の条件で検索してみたところ、 pubdate

    Teach Yourself Programming in Ten Years 日本語訳
  • Domain Parked With VentraIP Australia

    Domain ParkedThis domain name currently parked with VentraIP. ��� ��

  • 半年間休職してプログラミングの勉強をした - ぼっち勉強会

    目次 概要 この記事の目的 なぜ勉強するのか なぜ休職したのか(働きながらではダメなのか) どのようにして休職したか 金銭面の問題 勉強を継続するために気をつけたこと どのくらい勉強したか 何を勉強したか 反省 まとめ 概要 5月に休職しました。 休職開始から今日まで主にプログラミングの勉強をしていました。 11月から仕事復帰します。 この記事の目的 私が休職して勉強することを決めるとき、経験談を参考にしようと思い似たような方がいないか調べました。 しかし、私のニーズに合う情報はほとんど見つかりませんでした。 私と同じように休職勉強を考えている方にとって、少しでも参考になればいいなと思い書きます。 なぜ勉強するのか 私は業務ならば並以上の働きをしていると思っています。 社交辞令もあるでしょうが、社内・顧客ともに良い評価を頂いています。 一方で、経歴を増すごとに自分の中で技術力に対する不安が

    半年間休職してプログラミングの勉強をした - ぼっち勉強会
  • 2013-10-04 - Yamashiro0217の日記

    特に非エンジニア向けに書く。 プログラマー仕事はエディタに向かうことではない。 「お前は何を言っているんだ?」 まぁ、待って欲しい。説明する。 「将棋指しの仕事は駒を動かすことだ」 ?おかしいですよね。将棋指しの仕事は駒を「どう」動かすか考えることだ。 実際にレベルの高い将棋指し同士は、盤面が無くても脳内だけで試合ができる。 もちろん、プログラミングを実際に行なわないとコンピューターは動かない。 さらに例える。 プログラミング作業におけるコードをコンピューターに打つという作業は、 将棋指しが駒を動かす。というのに近い。 ただし、場合によっては駒の重さが30kgぐらいある。 どんだけ優れた将棋指しでも、30kgの駒を100回とか動かしたら、 疲れて頭回らなくて素人にも負けてしまうかもしれない。 30kgもある駒を動かすのは大変だ。 だからプログラマーはエディタ工夫したり、 開発環境工夫した

    2013-10-04 - Yamashiro0217の日記
    ruedap
    ruedap 2013/10/04
    この例え方ならデザイン作業でも同じかも
  • Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。

    常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という

    Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。
  • 僕はプログラマーです。

    僕はプログラマーです。 でも僕のMacBookProには何故かAdobeのソフトウェアが入っています。 iPhoneアプリのデザインをするわけではありません。 デザイナーの人がデザインファイルを.psdや.aiや.fw.pngのまま当然の様に投げて来るからです。 僕はAdobeのソフトウェアに精通しているわけではありません。 ですので複雑なレイヤー構造のファイルを切り出すのにはかなり時間を要します。 でもレイヤー構造の説明をしてくれるデザイナーの人は殆ど居ません。 デザイナー同士だとその複雑な構造でもやり取り出来るのかも知れませんが、僕には大抵よく分かりません。 例えば、Photoshopのエフェクトレイヤーが掛かっているボタンはボタンだけ切り出す時に凄く苦労します。 例えば、薄くシャドーが掛かってるデザインは素敵な質感を表現出来るかもしれませんが説明してもらわないとどこまで切り出したら良

    僕はプログラマーです。
  • Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT

    平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識

    Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT
  • 最近よく目にする「フルスタックエンジニア」とは何だろうか?

    このところ海外(おもに米国)のスタートアップで、「full stack engineer」の求人広告を以前より多く見かけるようになりました。フルスタックエンジニア、つまりインフラからミドルウェア、モバイル、デザインまで、あるいは設計からプログラミング、デプロイまで、何でもこなせるエンジニアを募集している、ということのようです。 例えば、このPublickeyでも導入しているコメントシステムの開発元であるDisqusは現在、「Full-stack Web Engineer」を募集しています。 「What We're Looking For」の項目では、5年以上のエンジニア経験とチームリーダーの経験などを求めた上で、技術的には次のような要件を並べています。 Very experienced with web application deployment and software design

    最近よく目にする「フルスタックエンジニア」とは何だろうか?
  • TOEICと留学。どのように英語を覚えるか。 - 素人がプログラミングを勉強していたブログ

    プログラミングというよりコンピュータにすら関係ないが、今日はTOEICと留学の話をしようと思う。 成果 2010年9月: 425点 2011年8月: 970点 背景 僕が英語を勉強しはじめたのは去年の9月、オーストラリアに語学留学した時だ。 留学すれば英語ができるようになるという根拠のない確信の元、事前の勉強無しで海外に飛び立った。 当時の英語力はほぼゼロに近い状態であり、諸事情で中学2年の知識の残りかす程度しか持っていなかった。 留学 おそらく、留学すれば自動的に英語が喋れるようになるというイメージを持っている人は多いと思う。僕も留学するまではそう思っていた。 しかし、現実は甘くない。勉強という形を取らずに自然に言語を覚えられるのは幼児だけである。 親切にma-maと1000回話しかけてくれる人がいない僕らは、教材を使って勉強しなければならない。 そこで、語学学校という選択肢が出てくる。

    TOEICと留学。どのように英語を覚えるか。 - 素人がプログラミングを勉強していたブログ
  • プログラマに向いていない人の特徴

    http://anond.hatelabo.jp/20130611130854 プログラマに向いている人の特徴は、よくまとめサイトやはてなで見かけますが、プログラマに向いていない人の特徴はあまり見かけたことがないので、10個挙げてみました。 顧客がバカみたいに見える自分が書いたコードを人に知られるのが嫌い(バグを)放っておく他人のコードを読んだことは一度もない何事も協力してやるより、一人でやったほうが質も高いし早いと思っている前段とわかりあえたことなどない(テスト)計画を立てない(コードを)変えようとしない)コードを見ればわかる。ドキュメントは必要ない口には出さないが、自分にはバグを作らない才能があると信じているいくつか似たようなのが含まれてますけど。 過去に出会った人々(自分も含め)の中で、「プログラマに向いていない」と思った人々の特徴をあげていってみました。さすがにこの特徴を全て満たし

    プログラマに向いていない人の特徴
  • Evan Priestley 氏がどうやってプログラミングを学んだかを教えてください - Knoh (ノウ) | The Knowledge Hub

    人による回答です。Evan Priestley 氏は知る人ぞ知る、Facebook を代表する (元) エンジニアの一人です。Facebook には 2007 年から 2011 年の間に在籍していました。 手短かに言えば: 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、(フェイスブックで働いていた) 過去4年間、ほとんど他のことをしていない。その前も2.5年ほどプログラマーとして働いていたし、そのさらに前も6年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば: 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで(最初はMac Plusで途中からIIsiになった)

    ruedap
    ruedap 2013/05/29
    前に読んだ文章だけど本当に良いね。繰り返し読みたい。質=スピード
  • かっこいいプログラマが欲しいなあ - 深沢克也の日記

    定期的にもやもやする なんか定期的にプログラミングの話が出てきて、そのたびになにやらもやもやします。 今回はそのモヤモヤを解消してくれそうな感じの記事があったので、その紹介と思うことをば。 プログラミングはそれ自体が目的であっていいって話。 とても理解できます。 プログラマって、もっと適当で良いと思うんですよね。 「理論的に」じゃなくて、もっと「感情的に」伝えたほうが面白いと思うんですよ。 ということで個人的には最初の方にあった以下の部分を広げて欲しいなぁ、とか思います。 僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 どうも、プログラマを目指す

    かっこいいプログラマが欲しいなあ - 深沢克也の日記