30代後半や50代からでもソフトウェア開発者になるのには遅くないという10人の実例
テクノロジー業界の発展に伴ってソフトウェア開発者の人材不足がいたるところで発生していますが、言い換えれば「プログラミングスキルを身につければ仕事に困らない」ということでもあります。とはいえ、「若いころならまだしも、30歳を超えてイチからプログラムの書き方を勉強するのは遅すぎるのでは」と思う人は多いかもしれませんが、下は35歳、上は57歳からプログラミングを習って成功を収めている10人の開発者が「ソフトウェア開発者になるのに遅すぎるということはない」と実情を語っています。 Is It Too Late to Become a Software Developer After the Age of 35, 40, or 50? And to learn programming? https://belitsoft.com/php-development-services/its-not-too
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
[Java] 連番-ウンコード・マニア
もはや人間が読むものではない。 その昔、「連番やめましょうよ」と提案したところ、「カンニングペーパーをモニタに貼っとけば、何のクラスかすぐわかるでしょ？」と言われて、早く脱出することを決意したことがあります。 package com.renban.erq053.czp008; /** * ZWQI001 クラス */ public class ZWQI001 { /** * m_F001 */ private String m_F001 = ""; /** * コンストラクタ */ public ZWQI001() { } /** * m_F001 を返却します。 */ public String get_m_F001() { return m_F001; } ..... 使い方ヒント: 「これは臭う」という行を見付けたら、各行のをクリックしてマーキングしておきましょう(要Twitter
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
博士の異常なアルゴリズム、または私は如何にして心配するのを止めて線形探索を愛するようになったか : 404 Blog Not Found
2012年02月10日13:00 カテゴリアルゴリズム百選アマグラマーのすすめ 博士の異常なアルゴリズム、または私は如何にして心配するのを止めて線形探索を愛するようになったか これはちょっとプログラマーといふ生物を買いかぶりすぎてると思います。 プログラマへの誤解 | pineapple blog プログラムを書かない人がプログラムを読んだときにする良くある間違いは，ああこんなプログラムなら自分にも書けそうだと思うことだ．プログラムは何百万とある可能性からたったひとつ（は言い過ぎにしてもわずかながら）の正しい方法を残したものであり，この捨てる能力こそがプログラマの実力だから． 少なくとも、プロ2グラマーの場合は。 その反証としてあげたいのが、線型探索(linear search)。漢字で書いたり英語で書いたりするとさぞ凝ったことをやってるように見えるけど、実は「見つかるまで頭から(あるいは
ぼくはこうしてプログラミングを覚えた
オリジナルはココです。フェイスブックのエンジニアでで史上ベスト３に入るといわれるEvan Priestley氏への質問「どうやってプログラミングを覚えましたか」に対する本人からの答えです。 手短かに言えば 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、（フェイスブックで働いていた）過去４年間、ほとんど他のことをしていない。その前も２.５年ほどプログラマーとして働いていたし、そのさらに前も６年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで（最初はMac Plusで途中からIIsiになった）で散々遊んだ。８歳か９歳
技術者のレベルとソフトウェア開発の難易度（9）: 柴田 芳樹 (Yoshiki Shibata)
これまでは、開発するソフトウェアの難易度と技術者のスキルレベルのミスマッチが発生すると開発が遅れたり技術的負債が残ったりしていくことを書いてきました。 実際の開発では、技術者のスキルレベルを直接測定する方法の決定版というものはありません。でも、きちんとした開発組織では、マネージャは技術者のレベルを把握していたりします。 なぜ、そうなるかというと、開発するソフトウェアの難易度を理解しているマネージャの場合には、技術者に開発業務を割り当てて開発してもらい、その進捗や成果物を自分の経験に照らし合わせて、技術者のスキルレベルを評価するからです。そして、どのような技術領域が不足しているか、そのためにどのような教育をしなければならないかも考えることになります。 これは実は非常に当たり前のことなのです。新人であれば、まずはその新人にとって妥当だろうと思われる開発業務を与えて、その成果次第でより難易度の高
ゼロからはじめるPSP ─Personal Software Process 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
私がソフトウェア技術者をやめた理由 - Rails で行こう！
昨日、 人生の転機 - Rails で行こう！ の中で「ソフトウェア作りが嫌いだ」と言い切ってしまったことが引っかかっている。 私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 簡単な例を挙げよう。 うるう年を計算するアルゴリズムを考えてみる。うるう年とは、「4で割り切れて、かつ100で割り切れない年。ただし、400で割り切れたら、やはりうるう年」である。 def leap_year?(y) (y % 4 == 0) && ((y % 100 != 0) |
サイボウズで学んだこと - IT戦記
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 （写真はゆうすけべーさんです） この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
派遣PG時代の思い出
@vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。 2010-05-11 12:42:06
ゲームプログラマーという職業はもうありません。 - teruyastarはかく語りき
暴言なのは分かってますが、 学生の頃ゲームプログラマーを目指した昔の僕に そのまま言ってやりたいセリフ。 こんな記事を見つけたので。 プログラマ、ＳＥ、ゲームプログラマについて - Yahoo!知恵袋 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1438427284 自分は将来、プログラマ、いずれはＳＥになりたいと考えていましたが、 最近では３Ｄも学んで、ゲームも作ってみたいと思うようになりました。 長時間労働、低賃金といわれていますが、やってみたいんです。 そこで、本題なんですが、 上記の仕事で働くには、今、どんなことをすればいいんでしょうか。 プログラマとして、働けるのは短いとか、 ゲーム業界は就職倍率高いとかは分かっています。 自分がやりたいのは、ＢＧＭとかグラフィックではなくて、 企画、制作、プログラムという部門
プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。彼らの考え方については、面接時に少しやり取りを行えばそれなりに見当が付くだろう。しかし、実際のプログラミング経験を推し量るのは至難の業だ。一部の企業では、さまざまなテストを実施することでこれを行おうとするものの、筆者の経験から言えば、こういったテストは近代的な開発環境では必要性が薄い知識（IDEのオートコンプリート機能や、F1キーの押下で表示されるヘルプ、インターネットといったものがあるため、ライブラリの知識は以前ほど重要ではなくなっている）の丸暗記能力を試すだけに終わることも多い。そこで本記事では、開発者を評価するうえ
退職したSEだけどなんか質問ある？
1 名前：以下、名無しにかわりましてVIPがお送りします：2010/02/12(金) 12:56:41.29 ID:nVm0xbnt0 無職歴１年だけど、特定されない程度に答えるよ 5 名前：以下、名無しにかわりましてVIPがお送りします：2010/02/12(金) 12:58:52.60 ID:8KWqyLR50 最高年収は？ >>5 400万程度 まぁまだ若造だったし 161 名前：以下、名無しにかわりましてVIPがお送りします：2010/02/12(金) 20:35:11.72 ID:JL2mEh7aP 1さんは理系ですか？ >>161 普通高校出て、専門で2年だけPGやってからの就職だから線引き難しいけど 一応文系です 9 名前：以下、名無しにかわりましてVIPがお送りします：2010/02/12(金) 12:59:57.34 ID:3aze5HBc0 デスマーチの実体 >>9 他
if 文と {} とコーディングスタイル - nothing but trouble
最近、また if 文における {} 省略の話をよく見掛けるようになった。何年たっても繰り返される話なんだろうなと思う。 なので、人のことをとやかくいう前に、自分のコードの変遷を考えてみると、簡単に言うと以下の様になる。 OOP 厨以前 {} 必須派 {} なしはバグの温床 OOP 厨時代 {} 以前に分岐ありえない {} 以前に分岐は悪。クラス分けするのが正義 OOP 厨脱却後 分岐はあり。{} は基本的に使わない 後々ややこしいことありそうだなと思うところは {} つける {} ありの部分は、将来リファクタリング入る可能性もあるので要注意 三項演算子の話も似たようなことでよく出てくる話なんだけど、どっちの話も同じような話で、そもそも意味がわかってないという人と、使いかたが合理的じゃないという人が槍玉に上げられてるような気がする。 で、そういうことが発生しないようなコーディング規約みたいな
25歳からプログラミング「泣きながら覚えた」 庄司嘉織さんのエンジニアライフ - 特集：No okyuu, No Life [okyuu.com]
赤毛に青いサングラス――独特な出で立ちのエンジニア庄司さんは25歳からプログラマーに転向した。プログラミングは「泣きながら覚えた」と振り返るが、いまやjava-jaを立ち上げるなど精力的に活動するエンジニアだ。 この企画はokyuu.com編集部が現在のエンジニア像をリレー形式で追っていくものです。 （取材・文＝編集部） 庄司嘉織（しょうじよしおり） 1975年7月22日生 34歳 ドワンゴ 研究開発本部 統合情報システム開発部 【略歴】 1996年3月 沖縄大学中退 2009年3月 株式会社ドワンゴ入社 ――ITエンジニアになったきっかけを教えてください。 庄司 プログラマーになる前は、契約社員で4年ほどパソコンのサポートをやっていました。中小企業のヘルプデスク業務を支援したり、プロバイダーの加入者をサポートしたり、仕事は多岐にわたっていました。インターネットが出たての頃だっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
http://post.simplie.jp/posts/34
プログラミングに関するあまり知られていない７つの真実