技芸(アート)における経験の重要性 - give IT a try
今日は過去に読んだことのあるWeb記事をふと読みなおして感じたことをつらつらと書いてみます。 プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（SIビジネスの本質編） － Publickey プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（クラウド時代の受託開発編） － Publickey プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（夢に挑戦できる社会にする編） － Publickey なぜ受託開発をやめたかというと、アジャイル開発が受託開発の中でうまくいかないんですね。 プログラマだからうまくいかないのかと思ってリーダーをやってみましたが、うまくいかないと。マネージャをやってみたけどうまくいかないと。営業で仕事をとってくるところかなと営業もやってみたんだけどうまくいかないと。 ではなにが悪いのかというと、受託開発というビジネス
普通のプログラマへ良いコードを書く方法を教える！リーダブルコード | Act as Professional
私はすばらしいコードを「エレガントなコード」と呼ぶ@HIROCASTERでございませう。 まず、はじめに。本書はハッカーは読まなくて良い。普通のプログラマに読んで欲しい。 デザインパターンやリファクタリングよりも、本書に書かれていることの方がプログラマは毎日考えて、意識してコードを書くのだ。 よって、普通のプログラマならば本書を読んでおきたい。普通のコードを書く人にオススメの1冊だ。 例えるならば、バク転や月面宙返りをする方法ではなく、日常的におこなわれる「歩く」という行動に着目し、姿勢良く、美しく、シッカリ、確実に歩くための方法が書かれている。 本書の目的は、君のコードをよくすることだ。 「良いコード」の定義とは、コードを読んだときに最短で理解できる様に書かれていることである。そう、本書は伝えている。 では、良いコードを書くための方法を具体的に学んだり、教えられたりしたことはありますか？
リーダブルコード
美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ。（本書「はじめに」より） コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
「Meteor」で来れ、1億総Webアプリ開発者の時代（1/2） － ＠IT
ものになるモノ、ならないモノ（47） 脅威のフレームワーク「Meteor」で 来れ、1億総Webアプリ開発者の時代 山崎潤一郎 2012/5/16 文系で印象派人間の筆者でも「これならWebアプリ開発、できるかも」と思わせてくれるフレームワークが登場した。技術的な視点からの開設は他所に任せ、ここでは、非プログラマの視点から、Meteorがどんな可能性を切り開いてくれるかを予想したい。 「1億総Webアプリ開発の時代到来か」「これなら印象派人間の俺にも開発できるかも」「『リーンスタートアップ』しちゃおうかな」……。 いま、「Meteor」という名のWebアプリケーション用フレームワークがエンジニアの間で話題になっている。この新しいフレームワークのサイトやそこで紹介されているビデオを見て、脳内ヘビロテ状態でグルグルとループ再生されたのが、冒頭のフレーズだ。 簡単でスピーディな開発を可能にした脅
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
Tumblr
この記事の対象: ユーザーインターフェイスやグラフィックスを扱うデザイナとプログラマ 昔話から始まって恐縮ですが、私が3DCGプログラミングに触れたのは今から20年近く前、当時学生だった清水亮氏がプログラミング雑誌に投稿していた記事やプログラムを見掛けたのがきっかけだったと思います。私は残念ながら「神童」ではなかったのでベクトルや行列については「チンプンカンプン」でしたが、いずれ3DCGを扱ってみようという気になった事は確かです。 その当時と今では、ハードウェアの性能、ソフトウェアの規模、そこから生まれるCGの表現力、何れを取っても桁違いになってしまいました。が、ベクトルを伸ばして、回して、移動させて、という操作がコンピュータグラフィクスの基本である事は何一つ変わっていません。 20年前の昔、家庭のコンピュータでベクトルや行列の計算をして画面にポリゴンを描くなどという事に興じていたのは、一
プログラマは自分がモンスターペアレントになっていないか気にするべき - プログラマyasuhoの隠れ家
そもそもエンジニア、モノづくりをするひとたちには一度作ったものには愛着を持ってしまう。それは自分が労力をかけたことに対する強い思いなのかもしれない。だから、作った機能がユーザーに使われないムダなものだとしても、開発エンジニアに愛着があることによって変更がかけられないなんてこともあるしね。 http://jp.techcrunch.com/archives/jp20120420how_do_you_reduce_the_cost_of_development/ そういう感情は確かにある。プログラマにとって我が子同然のプログラムのミスを見つけるテスターは敵であり「それはバグじゃなくて仕様だ」って言っちゃうところとか。使いにくいから直せという顧客に対して「それには構造を大きく変更しなくちゃならないから直せない」とか。プログラムの問題を見つけてくれた人に感謝するどころか「私は間違ってない！」なんて
何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
昔語りになってしまうが，私がペーペーの頃は制御系の業界でも C 言語を操る人はまだ比較的少なかった。ではなんの言語を使っていたかというと，もちろんアセンブラだ。だから「C 言語が使えます」ってのは結構売り文句だったわけだ。私も当時 C 言語は結構勉強したつもり。でもそこで学んだことはプロセッサのインストラクションを如何に効率的に C 言語に置き換えるかってことだった。「コード効率」という用語がある。最初からアセンブラで組んだ場合に比べて C ソースからアセンブラにコンパイルするとどの程度効率が落ちるかとい
昔語りになってしまうが，私がペーペーの頃は制御系の業界でも C 言語を操る人はまだ比較的少なかった。ではなんの言語を使っていたかというと，もちろんアセンブラだ。だから「C 言語が使えます」ってのは結構売り文句だったわけだ。私も当時 C 言語は結構勉強したつもり。でもそこで学んだことはプロセッサのインストラクションを如何に効率的に C 言語に置き換えるかってことだった。「コード効率」という用語がある。最初からアセンブラで組んだ場合に比べて C ソースからアセンブラにコンパイルするとどの程度効率が落ちるかという指標だ。コンパイラを出すベンダもこのコード効率で競争していた面があった。 プロセッサの機能を物凄く端折って言うとメモリ（ポートも含む）操作とレジスタ操作の2つしかない。 どんなシステムでも結局はその2つの機能のバリエーションを如何に組み合わせるかってことに帰着する。 凄く単純な話だ。 構
職業プログラマになって考えた「良いコード」とは？ - seri::diary
仕事としてコードを書くようになって３週間が経ったので ここらで所感をまとめてみたいと思う。 ベンチャーと大手企業の違いみたいなことを書いてもいいんだけど、 正直今のところ「あまり変わらない」印象。 それもそのはず、現職もエンプラ向けの仕事。 SIと仕事のやり方はかなり似ている。 ので、純粋にプログラマとして思ったことを。 スパゲッティコードとの出会い この３週間で触ったのはウチの会社で改修・保守をやっているシステムの バッチや管理画面の細かい修正など。 コードは全てPHPだった。 この辺は一番経験のある言語だったので助かった・・・と思った。 が、意気揚々とソースを見て愕然とした。 処理ベタ書きのずらずら続く手続き型の処理は序の口。 関数を定義する代わりにベタ書きスクリプトを外出しにしてrequire 意味不明な変数名 同じ処理をしているはずなのに名前だけ違う関数達 無計画なテーブル定義 業
今すぐフォローすべきPerl界のスーパーエンジニア - すぎゃーんメモ
今すぐフォローすべきnode.js界のスーパーエンジニア - 大人になったら肺呼吸の記事に便乗しまして。 独断と偏見に基づいて、自分がフォローしているPerl界隈の人から数人をピックアップして並べてみます。 @dankogaiさん blog: 404 Blog Not Found Perlへの言及はそれほど多くないけど 要所要所で鋭いツッコミが @hidekさん blog: hide-k.net#blog 同じ会社の人たちとの絡みが面白い。深夜のDJも注目 @Yappoさん blog: YappoLogs 基本的にネタ発言が多いけど面白いので大好きです @acotieさん blog: iDeaList::Writing Perl界の女性エンジニアでは最も有名？ @kamipoさん blog: かみぽわーる MySQLとかインフラな話とか。空mentionすると瞬時に返してくれるbot @w
プロとしての行為 Act as Proffesional
1．一般的なコーディング規約に目を通し、エレガントなコードを知るエレガントなコードを書くためには、エレガントなコードを知らなければならい。その土台を築いているコーディング規約について、オープンソースではどのようなものが使われているのか理解しておこう。入社する予定の会社が採用している言語については必ず目を通しておこう。 PHPPEAR 標準コーディング規約symfony CodingStandards Perlperlstyle Ruby クックパッド株式会社のRubyコーディング規準 Matzスタイル NaClで採用している規約 Python PEP 8そして、あなたの身近にあるオープンソースのコードを実際に読んでみよう。この時点でコードの仕組みや設計が理解できなくても良い。コードがエレガントかどうか？を感じ取って欲しい。こう書いた方が、良いのではないか？など、考えてみよう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.2ch-search.net/blog/3
プロとしての行為 Act as Proffesional
Qiita
プログラマと付き合う