A Million Hello Worlds - steps to phantasien
テクノロジの流行をファッションに例えて揶揄することがある。新しいテクノロジを追いかけてばかりいるプログラマを非難し、勉強会もいいけど問題解決に頭を使えという。 ファッショナブルなプログラマを責めるのは、衣服や装飾品で散財する人を無駄遣いせず金を貯めろと責めるのに似ている。ユニクロ・無印・（その他無難なブランド）でいいじゃん、それより体でも鍛えなよ、なんて説教するかんじ。一理ある。でも話が通じる気はしない。 おしゃれ貧乏はさておき、人々はなぜ身だしなみに気を使うのだろう。周りと同じがいいなんて消極的な理由もあろう。特定の文化的集団、サブカルチャーに参加するためかもしれない。反対に人と同じが嫌だからかもしれなければ流行りに詳しいところを見せたいからかもしれず、単に目立ちたいからかもしれない。演出したい自己像を求める人もいれば洋服マニアもいる。防寒や衛生や法令遵守だけが衣類への期待とは限らない。
「プログラマとして食べていく」という話を福井県の学生さん達にしてきました - その後のその後
一昨日、福井県の「ふくい産業支援センター」さんが主催されたセミナーで、標題の講演をさせていただきました。資料はこちら。 参加者約70名のうち、75%は18歳以上の大学生・専門学校生、15%が高校生・高専生、10%が小中学校。これまでエンジニアの中で話をする機会は多々ありましたが、学生さんばかりの中で話すのは初めてでした。 内容 内容としては、「プログラミングでこんな感じでメシを食ってる人がいる」という一つの参考例として自分の働き方を紹介しつつ、プログラマとしてとりあえずやっていけるようになるまでの話と、フリーになってからおもしろい仕事を得るためにどんなことを考えながら働いているか、の3部構成でした。 50分と長尺の講演だったので、最後にFAQをくっつけて時間調整できるようにしておいたのですが、6つぐらい用意しておいたうち2つぐらいしかしゃべれず。話したうちのひとつは「お金の話」だったのです
ソースコードって実際のところどういうふうに書いていますか？｜Rui Ueyama
私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい
ソフトウェアのプロとしての態度 - ちなみに
Clean Coder プロフェッショナルプログラマへの道 作者: Robert C. Martin,角征典出版社/メーカー: アスキー・メディアワークス発売日: 2012/01/27メディア: 大型本購入: 12人 クリック: 645回この商品を含むブログ (36件) を見る Clean Coder を読みました。 日本語版は2012年発売で、去年2014年の誕生日に頂いたものだったのですが、やっとこさ読み終わりました。 貰ってすぐに前半を読んでいたのですが、途中で止まってしまっていて、今期の目標を技術書を読むことに設定したのを機に、通勤時間に少しずつ読み進めて2ヶ月くらいで読みました。 さらに読み終わってから1ヶ月ほど経過していて、とにかく怠惰。 ボブおじさんことRobert C Martinの著書で、ソフトウェアのプロとしての考え方や振る舞いについて、豊富な実体験を元に解説されている
公式ドキュメントを読もう — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 最近、若手のエンジニアと話をする機会が多くあります。そういった場で、ここが重要ですよと伝えたい話のうちのひとつがこの話になります。別のところに書いていたものですが、すこし手を入れた上で再掲します。 ハッカーの世界には昔から「RTFM」という言葉があります（参照）。ようするに「マニュアルを読め」という言葉なのですが、これはとても重要な言葉です。 色々な人によってブログにメモやノウハウが記載され、簡単に検索でみつかる世の中ではあります。また、そのためのサービスや技術的な質疑的な質問をすることのできるサービスも沢山あります。 しかし、検索サービスは、その内容が正しいことまで保証してくれません。見つかった記事の著者が誤解している場合もあれば、理解していない場合もあります。そして、ほとんどの場合は最新の情報ではありません。 マニュアルや公式ドキュメントであれば、それ
国語力とプログラミング力の関係 解説編
2009年1月、Cyan設計者 林拓人氏とLispの伝道師 竹内郁雄氏との対談「Cyanを設計した高校生、5カ月で5つの言語を習得」が大きな反響を呼んだ。その原因の1つは、竹内氏が発したひと言「わたしの持論ですが、国語ができる（＝日本語できちんとした文章が書ける）人じゃないとプログラムは書けない」だ。これについてネットでは同意する意見が多かったものの、記事中で根拠が明らかにされていなかったため議論が紛糾した。そこで編集部は竹内氏に詰め寄り、「わたしの持論」について詳しく説明してもらうべく寄稿をお願いした。国語力とプログラミング力には本当に相関関係があるのだろうか。 事のいきさつ～Cyan設計者 林くんとの対談で発してしまったひと言が思わぬ反響を呼ぶ Cyan言語で経済産業大臣賞を受けた開成高校の林拓人くんと対談（「Cyanを設計した高校生、5カ月で5つの言語を習得」）しているうちに、つい調
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
Web エンジニア 6 年 5 ヶ月やってたどり着いた価値観 | Born Too Late
Web エンジニアとして経験を積むことでいくつかのプログラミング言語やツール・ミドルウェアの使い方を覚えたりもしたけど、それらのうちいくつかは 10 年後ぐらいには陳腐化してしまっているかもしれない。 だけどそれらを通じて身につけた価値観や哲学はもっと普遍性を持っているような気がする。 大学を卒業し、Web エンジニアとしての職を得て 6 年 5 ヶ月、日数にして 2344 日経ったので、現時点での頭の中にあるもののダンプを残しておく。 どこかで聞いたようなことばかりで新鮮味はないと思うけど、自分で実感を持ってたどり着けたことには意味があるはず。 プログラミングについて 言語はいろいろなものを試してみる 毎年新しい言語に挑戦せよ、というのは確か dankogai さんの講演をまとめた記事で読んだはずなんだけど、記事が見つからない。 キーワードをもとに検索してみたら達人プログラマーにもそうい
続: OSSプロダクトとコミュニティの話 - たごもりすメモ
先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。 t-wada.hatenablog.jp t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。 明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。 なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく
今日のポエム: なぜ、その抽象化は失敗してしまうのか - Line 1: Error: Invalid Blog('by Esehara' )
近況 打ち捨てられた過去について 要旨 この記事を興味深く読む一方で、やはり違和感を覚える人も多くいるようで、自分もその一人だった。恐らく、この違和感は、「抽象化」が「具体性を奪取していくもの」といったような対立項として述べられているからだ、というように思われる。しかし、果たして具体性無しに「抽象化」することが有益なことなのだろうか。それが一つの違和感のように思われる。 本文 プログラミングの世界には、YAGNI原則(You ain't gonna need it)というものがある。また、YAGNIという言葉を使わなくても、「過度な汎用化が足を引っ張る失敗例」というのは、プログラマとしての心構えを書いた本の中で、ちらほらと自嘲気味に述べられることがある。 僕も、一度そのような失敗例を見たことがあるけれど、なぜこういう失敗が起こるのか。確かにデザインパターンで組み立てられたアーキテクチャは「
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
トヨタの車のソースコードはスパゲッティコード山盛り？ - YAMDAS現更新履歴
Toyota Unintended Acceleration and the Big Bowl of “Spaghetti” Code | Safety Research & Strategies, Inc. O'Reilly Radar で知った記事だが、この記事自体は2013年、トヨタがオクラホマ州での急加速を巡る訴訟で和解した後に書かれたものである。 この記事で面白いのは、Michael Barr が20ヶ月以上にわたりトヨタ車で使われているソースコードを、Philip Koopman カーネギーメロン大学教授がトヨタのエンジニアリングの安全プロセスを精査した話で、両者ともトヨタのソフトウェアがスパゲッティコード山盛りなことを証言している。 トヨタの生産方式はアジャイル方面においてソフトウェア開発手法に多大な影響を与えている。ところでそのトヨタが開発するソフトウェアの品質はどうなんだ
Suffering-oriented programming - thoughts from the red planet - thoughts from the red planet
September 2021 (1) March 2017 (1) January 2017 (1) July 2016 (1) June 2016 (1) September 2015 (1) October 2014 (1) June 2014 (1) May 2014 (1) February 2014 (2) April 2013 (3) March 2013 (1) September 2012 (1) February 2012 (1) January 2012 (1) October 2011 (1) March 2011 (1) January 2011 (3) December 2010 (2) November 2010 (1) October 2010 (2) August 2010 (2) July 2010 (2) June 2010 (1) May 2010 (
Code Review Best Practices
At my current company, we do a fair amount of code reviews. I had never done one before I started here so it was a new experience for me. I think it’s a good idea to crystalize some of the things I look for when I’m doing code reviews and talk about the best way I’ve found to approach them. Briefly, a code review is a discussion between two or more developers about changes to the code to address a
女の子らしくコードを書く、ということ – Medium Japan – Medium
この記事の元となっているプレゼンテーションは、オークランドで開催された AlterConf のものです。テーマはジェンダー・ダイバーシティについてでした。同カンファレンスでは、人種差別、障害、階級差別など多様なテーマについてのプレゼンテーションが行われていました。 Always （訳注：女性用品のブランド）の広告で、成人の男女に「走る・叩く・投げる」を女の子らしくやってもらう、というものがあります。頼まれた人々がそれをおこなう様子は、なよなよしくてひどいものでした。その広告では、次に、同じことを若い女の子達に頼んでみます。すると、彼女達がそれをおこなう様子はまさに「精一杯・一生懸命」でした。その後、「女の子らしくやる」ってどういうことかな？と尋ねてみると、女の子の1人がこう返します。「自分に出せる全力でやる、っていうことよ」。 残念ながら、ある程度年をとると、「女の子らしく何かをする」とい
Jacob Kaplan-MossのPyCon 2015における基調講演: プログラミングの才能という都市伝説
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTube The programming talent myth [LWN.net] PyCon 2015で、Djangoの貢献者であるJacob Kaplan-Mossが興味深い基調講演をしているので紹介する。LWM.netでほぼ全面書き起こしに近いまとめがあったので助かった。 自己紹介 Kaplan-MossはDjangoの貢献者であり、Herokuのセキュリテイ部門の部長である。PyCon参加者としては歴史が長く、その他のカンファレンスでもよく発表している。Pythonコミュニティは「自分にとってこの業界におけるとても重要なもの」であり、PyConの基調講演を行うということは、「自分のキャリア上の絶頂」である。 自分の最初のPyConの発表は2005年のことで、PythonとAppleScri
ダメなコードを改造しなくてはいけなくなったときは、ダメさを片っ端から潰していくしかない
仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
優秀なエンジニアになる方法: 電子情報通信学会誌 Vol.84 No.10 pp.741-749 2001年10月
Clojureシンタックスハイライター開発から考えるこれからのlispに必要なもの
