プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
絶対落ちないアプリの作り方
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
仕事とは、プログラミングとは - mizchi's blog
これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら
多くの若きプログラマたちが学ぶべきこと | POSTD
私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン
「10倍プログラマ」の神話、Ruby on Railsの生みの親が語った高い生産性のカギとは!? | HRナビ by リクルート
ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。 Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。 2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
優れたプログラマに対しての、管理職への昇進以外のキャリアパス | POSTD
あなたは、これからキャリアを切り拓こうとしている素晴らしいエンジニアたちを抱えています。チームは優れた成果を出して成長し続けているので、何らかの具体的な方法で賞賛したいと考えています。すぐに思いつくことは、特にエンジニアたちがそのチーム内ですでに事実上リーダーの役割を果たしている場合には、彼らにチーム内での役職を与えて昇進させることでしょう。でもその報酬は、本当にエンジニアたちが望んでいるものでしょうか？ もしかしたら彼ら自身も、昇進は望むべきもの、と思い込んでいるだけではないでしょうか？ 人材マネジメント力は別のスキル エンジニアの世界では、エンジニアたちが技術面ではピークに達した後に、これまで習得したものとは全く別の、社交面だとかソフト面におけるスキルを学ぶよう求められることがよくあります。これらは、エンジニアたちが過去のキャリアではほとんど気にしていなかったものです。このようなスキル
Matzさんに聞く、新卒エンジニアの適正年収は？ | 株式会社VASILY(ヴァシリー)
RubyのパパことMatzさんに、新卒エンジニアの適正年収を伺いました。twitterで下記のようなコメントがあり、弊社も新卒採用などやっていることから、Matzさんに新卒エンジニアの給料について伺ってみました。 質問 新卒エンジニアの適正給料はこれだとするならいくら位だと思いますか？ざっくり。 Matz 日本ということ考えて…理系大卒で600万くらいかなあ でもねぇ、大卒はだいたい粒ぞろいだと言っているのと同じ。個人差は無いものとしているってことなので、それだとおかしいよね。 ただ、コンピュータサイエンスの学科を出て、プログラミングできるっていう学生が300万とか400万とかしか貰えないと、彼の持ってる技能はあまり評価されてないってことじゃないかなと。特殊技能を持っていると思われてないってことじゃないかな。 プログラミングするのに国家試験はいらないので誰でもなれるって思われ
プログラマの悩み。大したスキルもないし、この先ほんとに大丈夫かな→少し自信が持てた話 - PCがあれば何でもできる！
Webエンジニアになろうと決心し、行動を開始したのが、9ヶ月前の12月。 そして現在は… スマホアプリをメインで作っている企業に、転職することができました。 スキルで言うと、AWS、Rails、Java、副業でPHP、AngularJSの辺りを使いつつ、ようやくWebエンジニアと名乗れるくらいには、なってきたかなと思います。 どうやってここまで来れたのか、お伝えできると良かったのですが…。 正直な話、自分の努力よりも、現職・前職の職場の方々、そして家族が支えてくれたというのが大きいです。 そのため、あまり皆さんの参考になるようなことは、書けそうにありません。 ただ、今回、色々と動いてみて、 「今の自分には、スキルも知識も何もない」という悲観的な考えから、 「もっと自信を持っていいんだ」と思えるようになったことは、大きかったです。 今日は、そう思えるようになったきっかけについて書いてみようと
プログラマ歴12年の僕が選んだ「10年経っても役立つ技術書17選」 - give IT a try
はじめに 僕がプログラミングを始めてから、もうすぐ12年になろうとしています。 この12年間、いろんな技術書を読んだり、仕事やプライベートでたくさんコードを書いたりしてきました。 最初に入ったSIerでは主にJavaを、前職の社内SE時代はC#をメインのプログラミング言語として使ってきました。 現在はRubyをメインで使っていますが、言語が変わっても、また何年経っても「これはあのとき学んだ知識が役に立ってるよなあ」と思う瞬間がときどきあります。 そこで今回はこれまでに読んだ技術書を一通り振り返り、「この本で学んだことは今でも役に立ってる」と思うものを17冊ピックアップしていきます。 おことわり (2014.09.29 20:00追記) このエントリのタイトルは「10年経った今でも役に立っている」という意味で付けています。「今から10年後まで役立つ」という意味ではありません。（紛らわしくてご
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 この記事について この記事は、新人向けの研修内容を再編集してお送りします。 この記事の内
プログラマ格言(2006)
2006年くらいに書いたプログラマ格言が発掘されたのでおいとく。おおむねダジャレです。 * PHPを笑うものはPHPに泣く * 意味: 「PHPなんてまともなプログラミング言語じゃないよ」と笑っていたら仕事でPHPを触るはめになってしかも既存のソースが汚かったりして泣く。 * 教訓: 好き嫌いを通せるようにえらくなれ。 * ソースが知れる * 意味: 変な挙動をするソフトをさわっていると、動き方から間違ってるパターンと作った人のレベルがなんとなく透けて見える。 * 教訓: どうやったらうまく動くか探すのも仕事のうちらしい。 * ひいきのwiki倒し * 意味: 「wikiはすばらしいツールですよ！」 と、とにかくwikiを導入してメンテ不良のページを大量につくってしまう。 * 教訓: 情報共有ツールは使う人のメンテナンス能力が一番のネック。 * ライブラリからボタ餅 * 意味: 延々ぐぐっ
プログラマが体験するべき○つのこと - laiso
プログラミングはそれ自体が目的であっていい - mizchi log 大事なのは、いくつ地雷を踏んだか、だ。地雷を踏んだ数だけ強く慣れる。真に必要なのは、独力での問題解決能力。Python2系でsjisのHTMLをlxmlでスクレーピングすると、地雷を7つぐらい同時に踏めるからおすすめだ。 僕もまあそれなりに手を出しているのだけど、他の人も抑えるべきだと思った概念は、次のものだ。 Haskellにおける入出力IOと副作用の概念 HaskellのMaybe, またはScalaのOption型 Scalaのtrait Node.jsの非同期Promiseパターン C#のgetter/setter/readonly/async等の型アノテーション 本題にはあんまり興味がなかったんだけどこの部分がおもしろかったのでイッチョカミしたい。 成功体験の共有とまではいかないけど、こういう「これはやってよか
新人SEがSIerに絶望した時に読みたいスライド4選 - ギークに憧れて
新社会人の皆さん､いかがお過ごしでしょうか｡ 最近､SIerに就職した知人が｢会社辞めたい｣というのをちらほら聞く｡聞いてみれば､彼等は仕事で挫折しているわけではない｡むしろ､技術に優れ熱意を持っている事が多い｡ではなぜ辞めたいのかと聞けば､一日中画面のスクリーンキャプチャ撮らされたりCOBOL読まされたりしていて､｢ああ､そっか…そうだよね…｡｣となる｡ そんな時は､SI業界の熱い人達のスライドを見て何かを感じよう！という事で4つ選んでみた｡弊社関係者が多いのは僕のネットウォッチの都合上お許しください｡moon and strategy moon and strategy from toshihiro ichitani 永和の@papandaさんのスライド｡｢自分の生き方を他人任せにしない｣受託プログラマの進路〜アジャイルセールスと手塚モデル〜 受託プログラマの進路 〜アジャイルセールス
4月にプログラム始めた人がゴールデンウィークに積んでおく本 - きしだのHatena
大きく挙げたのは7冊なので、7日の休みで1日1冊ですね！ 連休の間に読んでおいて、友達に差をつけよう！ うっかり、先輩にも差をつけちゃえばいいと思います。 プログラムを組むとはどういうことか 本を挙げる前に、まずプログラムを組むとはどういうことかということを考えておきます。 ざっくりとした説明なので、だいたいこういう感じ、だと考えてください。 その上で、どのような本が必要かを考えて、本を選んでいきます。 以前描いたものですが、プログラムを作るということと各分野の関係はこのようにあらわせます。 まず、プログラムは最終的にユーザーに使ってもらうためのものです。 ただ、ユーザーはプログラムを直接使うことはできません。プログラムはハードウェアで動かす必要があります。そして、ユーザーインタフェースを介してユーザーが使います。 (ハードウェアからプログラムへの矢印は逆のほうがいいですね) このような、
langturn.com is coming soon
is a totally awesome idea still being worked on. Check back later.
マネージャになりたくないプログラマのキャリアパス
金曜日、KLab元CTOの仙石さんからありがたい話をいただきました。 話は、開発者の採用、教育、評価あるいは開発者の心構えなど多岐に渡りました。いくつも興味深い話がありましたが、個人的に一番聞いて良かったと思える話を紹介します。表題の件です。 若いプログラマの中には年をとってもマネージャになりたくないと言う人がいます。他人事ではなく自分もそのひとりでした。若い時にマネージャ志望のキャリアパスに語ることは、プログラマとしての自分の誇りを傷つける気がしていました。マネージャを偉いと見なす風潮が、技術に対する裏切りのような気分がしていました。技術者をマネージャより低いと位置づけるのが許せませんでした。 たぶんピュアだったのでしょう。そんな経験があるので、今でもピュアな若者は好きです。本物のプログラマになるには、技術だけに一心に向き合うピュアな期間が必要だと信じています。そして、技術に真摯に向き合
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー // Speaker Deck
