プログラマーに憧れる子供たちに周知せよ、人月商売と本物のIT業界は別物だぞ
世の中の職業をこんなふうに2つに分けてみる。1つは基本的に「この仕事をやりたかった」という人だけで担われている職業。もう1つは「この仕事をやりたかった」という人だけでなく、「仕方なく」「たまたま」という人も数多く流入してくる職業だ。前者の典型は、例えばプロ野球選手だ。実際に「仕方なく」「たまたま」選手になった人は皆無だろう。 プロ野球選手なんて例に出すと、「この仕事をやりたかった」という人だけの職業は極めて特殊な印象になるが、実際はそうでもない。その仕事をやりたいと思うならそれなりの能力や適性、努力が必要で、その仕事に就いた後もレベルアップを目指して常に研さんを積む必要がある職業であるなら、全て含まれる。もちろん、なかには「仕方なく」「たまたま」その仕事に就いたという人もいるかもしれないが、あくまでもレアケースのはずだ。 プログラマーも本来「この仕事をやりたかった」という人たちが就く職業で
過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方
さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏：リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。
技術者の仕事を自らおとしめる愚か者たち、人月商売の「身分制」に異議あり
人月商売のIT業界の多重下請け構造は「多重ピンハネ構造」だ――。こんな趣旨の記事をこの「極言暴論」で何度か書いてきた。すると、「SIerの技術者と下請けITベンダーの技術者ではやっていることが違うので、待遇に差があって当然だろ」という文句が必ず何件か来る。「私たちが下請け技術者の仕事をつくってやっている」と暴言を吐く連中よりはましなのだが、私から言わせれば「何を言ってんだか」である。 もちろん、仕事の内容や能力が異なれば、報酬などの待遇が違って当たり前である。文句を言ってくる人は「やっていることが違うので待遇が違って当たり前」と言い切るのだから、優秀なプロジェクトマネジャーかSEなのだろう。もしプロマネなら反対に聞いてみたいことがある。それは「だったら、何で年収1000万円前後の安い給料で満足しているのか」ということだ。本来なら2000万円以上、大規模案件を切り回せる人ならば3000万円を
ノーコードの限界は意外と近い まつもとゆきひろ氏が語る、プログラマーが仕事する相手は“人間”ということ
ノーコードの限界は意外と近い ーー小学校でプログラミングを勉強することになったり、プログラミングスクールが増加したりと、プログラミング自体はより普及が進んでいる時期だと感じます。そんな中で、ノーコード開発が普及することに、どのような印象をお持ちでしょうか。 まつもとゆきひろ氏（以下、まつもと）：私自身はプログラミングができる立場なので、なかなかノーコードとローコードの領域に対して、魅力を感じにくいところがあると思います。ただ、懸念に思っていることはあります。例えばノーコードと言っても、本当になにもしないで望むものを得られるわけではありません。なんらかのかたちで、何を望んでいるかを伝えないといけないわけです。 ノーコード開発と言われているものでそれができるのは、領域を非常に絞って、既存の部品の組み合わせによって目的を達成できるからだと思うんですよ。しかし、人間のやりたいことは多岐にわたってい
天才プログラマー登氏に聞く、日本が「海外に負けないICT技術」を生み出す方法
諸外国に後れを取る日本のICT産業。その発展を担うICT人材不足も深刻だ。企業や行政は、どのようにして優秀なICT人材を育成すべきだろうか。「天才プログラマー」との呼び声もあるソフトウェアおよび通信ネットワーク研究者であり、「シン・テレワークシステム」の開発者でもある登 大遊氏に話を聞いた。 ソフトウェアおよび通信ネットワーク研究者。SoftEther VPNを開発・製品化・オープンソース化し、全世界に500万ユーザーを有する。外国政府の検閲用ファイアウォールを貫通するシステムの研究で、筑波大学で博士（工学）を取得。2017年より独立行政法人情報処理推進機構（IPA）サイバー技術研究室を運営。2020年にNTT東日本に入社して特殊局を立ち上げ、シン・テレワークシステムを開発。ソフトイーサを17年間経営中。筑波大学産学連携准教授 テレワーク難民を救った「シン・テレワークシステム」 新型コロナ
継続的インテグレーション - Wikipedia
継続的インテグレーション（けいぞくてきインテグレーション、英: continuous integration、CI）とは、すべての開発者の作業コピーを定期的に共有されたメインラインにマージすることである。1日複数回行われるのが一般的である[1]。グラディ・ブーチは1991年のメソッド[2]でCIという用語を最初に提案したが、彼は1日に数回の統合を提唱していなかった。エクストリームプログラミング(XP)ではCIの概念を採用し、1日に1回以上、おそらく1日に何十回も統合することを提唱した[3]。 理論的根拠[編集] 開発者は変更に着手するとき、現在のコードベースのコピーを取って作業する。他の開発者が変更したコードをソースコードリポジトリに提出すると、このコピーは徐々にリポジトリのコードを反映しなくなる。既存のコードベースが変更されるだけでなく、新しいコードを追加したり、新しいライブラリやその他
新人プログラマをレビューで傷つけないために - Qiita
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
未経験からのプログラマーなんだが全然分からない
未経験でもOK！教えます。というプログラマーの求人があったので、応募してみたら受かった。 受かったは良かったものの、仕事はざっとやるべきプロジェクトの説明、ソースの説明をした後、はい頑張って！！で丸投げ。プログラマー未体験の私、何も分からない。言語はJava。リーダーは自分も何も教えられない所から頑張ってきた、それですごく勉強になって出来るようになったと語るが、この方は元々頭良いと思うし、プログラマーやる前Webデザイナーもやってたから言語の理解も私よりアドバンテージがあった。対する私、まともにPCを使う仕事にすら就いたことがない。 ヒントを教えてもらっても、それでも分からない。何も分からないまま半月が経ってしまった。Java入門書も買ったが、やってる事に対する理解が追いつかない。あと、仕事が終わったら疲れて勉強出来ないのも問題。リーダー曰く、私は手を動かす回数が少ないからもっと色々試して
【保存版】プログラマ・エンジニアを評価する方法
掲題に関する問いを Facebook に投げたところ、素晴らしい回答がたくさん集まったので、この知をより広く知ってもらうため、そして後世に残すために、内容をまとめておく。 【問い】 プログラマ・エンジニアを評価する方法 先日「自分が正当に評価されていないと嘆く君へ」という、組織における人事評価に関するエントリを書いたせいで、読者の方からこんな相談が寄せられました。 皆さまの忌憚なきご意見・知見をお寄せいただきたく！ <相談内容> 例えばゲームやアプリの開発って、結果(アウトプット)が現れるまで数年ぐらいかかったりします。 その数年間の間に、真剣に作業に取り組む人もいれば、適当にサボる人など、色々差が出ると思うのですが、どうすればその差を、数年ではなくより(なるべく)短いサイクルで可視化できるものでしょうか？ 評価の制度や指標をどのように設計すればいいか、あるいは、どのような設計方法があるの
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
適切な抽象度を求めて #5
以前に思いついたジョークでこんなものがある。 初級プログラマへのアドバイス コードを読みやすくするために、もっと抽象度を上げよう。 上級プログラマへのアドバイス コードを読みやすくするために、もっと抽象度を下げよう。 これはジョークなんだけど、抽象度が低すぎても高すぎてもコードは読みにくくなる、というのはある程度当たっていると思う。 抽象化が低すぎるケースを考えてみよう。数百行もある長大な関数に何十もの変数があり、ループのネストはやたら深いし、しかも変数は途中で別の用途に再利用されちゃっている、なんていうとんでもないことになっているコードを見たことがはないだろうか？私はある。というのも私は長いこと、そんなコードばかり書いていたからだ。複数の関数に分割するなり、状態を構造体にまとめるなり、変数のスコープを制限するなり、抽象度をあげることでコードを読みやすくできる、ということを学んだのはだいぶ
プログラマ向け：自分の強みや得意分野を見つける方法 - give IT a try
質問：あなたの強みや得意分野は何ですか？ プログラマのみなさんに質問です。 あなたの強みは何ですか？ 胸を張って「任せとけ！」と言える得意分野はありますか？ これはソニックガーデンの採用面談でよく聞かれる質問です。 僕もときどき採用希望の人と面談（という名の雑談）をすることがあるのですが、この質問に対して「はい、私はxxが得意です！」と即答できる人はかなり少ないです。 まあ、入社を希望する段階でいきなり「これが得意です！任せてください！」と言うのはかなり勇気がいりますよね。 下手に偉そうなことを言って、あとから「なんだ、大したことねーな」と思われたくない、という不安もきっとあるでしょう。 僕もかつては即答できなかった 何にせよ、即答できない気持ちはよくわかります。 実際、ソニックガーデンに入社した当時の僕もそうでした。 しかし、入社してから3年ほど経ってみると、いつの間にか僕にも得意分野（
日本でプログラマが少ない理由は戦う戦場を間違えているからです - 文系プログラマによるTIPSブログ
2015-03-08 日本でプログラマが少ない理由は戦う戦場を間違えているからです IT業界 ◯ 広告 昔から言われている日本のプログラマ問題、さて、皆さんどう考えているのでしょうか。 日本でプログラマが少ない理由は正当な対価を支払わないからである : SIerブログ この記事を読んで、色々と思うところがありました。 社長や偉い人の見解 日本史なんか教えなくていいからプログラミングを教えろ、日本でプログラマが足りない理由は 工学系とかプログラム系を学ぶ学生が少ないから http://wirelesswire.jp/london_wave/201503031606.html まあ一理あるとは思いますが、ちょっと浮世離れしている感が否めません。 スレ住人の見解 続いてスレ住人達の見解です。こちらは現場サイドの意見が見られます。 ぶっちゃけ日本人は能力格段に低い 日本のIT企業はコミュ力で勝
IT業界でありがちな説明下手について - 文系プログラマによるTIPSブログ
横着しちゃいかんのです。 IT業界に限った話しではありませんが、説明下手な人っていますよね。 私がIT業界でよく日頃から感じている説明下手（質問下手とも言う）なエピソードについて書いてみます。 例 この話から私が理解できた部分 この話から私が理解できなかった部分 どうして話が伝わらないか どうすれば伝わったか こういう質問が返ってきたら説明下手かも！？ 雑感 例 やらないおさん、落ちちゃうんですけど、getHoge()のこの部分があれで、多分ああなんじゃないかと思うんですけど、どうすればいいですか？ ？？？？ え？ごめん。何の話？いきなりソースコードの具体的な箇所の話されても理解できないから、落ち着いて順を追って話してみようか ※ 以降、質問をする側を「やるお」、される側（私）を「やらないお」とします。 ※ getHoge() メソッドはやるおが自分で作った独自メソッド。当然やらないおは知
1443641775
よく「どうやって情報手に入れてるの？」みたいに聞かれますが、そんなの、ひたすら時間かけてgithubみたりメーリングリスト読んだり最近ではgitterの会話読んでるに決まってます。 どうやって(How)ではなく、なぜ(Why)、自分がそんなことをするようになったのかを、あらためて書いてみる気になったので書いてみたいと思います。 書こうと思ったのは、Howだけ書いても、Why書かないとあまり意味ないと思うことが多くなったからですかね。(この件に関しては) 無責任に大雑把にいうと、(どんな理由であれ)情熱みたいなものがあれば、Howは自然に身につきます、たぶん。 なお、少し長くなるし、自分語りっぽくなるし、いつも書いてるようなものとは少し方向性が違い、具体的なすぐ役に立つ技術的な内容*1は基本出てこないので、期待してるものが違うと思う人は、ここで読むのやめたほうがいいと思います。 どれほどコー
プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
日本語版がでました。すぐ買うべし。 SOFT SKILLS ソフトウェア開発者の人生マニュアルposted with amazlet at 16.05.18ジョン・ソンメズ 日経BP社 売り上げランキング: 1,272 Amazon.co.jpで詳細を見る Soft Skills: The Software Developer's Life Manualは残念ながら日本語訳が出ていない。でも英語でも読む価値はある。とても平易な英語で書かれてる。どこかの出版社さん翻訳だして欲しい。空前のブームになるに違いない。 Soft Skills 。alc.co.jp によればソフトスキルは「対人的な交渉・指導・意思疎通などをうまく行える能力（または知恵）」のことらしい。そのタイトルからも分かる通り、プログラマ向けに書かれた本だがほとんど技術の話は書かれていない。プログラマとして生きていくための技術以外
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
プログラマ能力指標表 | POSTD
2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『絶対にバグがとれる最強デバッグ法』プログラマーを中心にさまざまな職業の方から共感集まる「自分の悪いところをまず取り除け」
NOOK
