良いコードの書き方 - Qiita
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
２つのことを同時に学ばない
こんにちは、ある人のところてんです。プロシンという情報処理学会の<s>新年会</s>学会にかれこれ15年くらい参加しているわけですが、本稿はそこで水島さんと話をした「2つのことを同時に学ばない」という考え方についてのまとめになります。 初手レイトレーシング「２つのことを同時に学ばない」というのは私が発した言葉ですが、この言葉には私の友人の影響があります。 私の友人に「新しいプログラミング言語を覚える際には、とりあえずレイトレーシングを書いてみる」と言うやつがいます。 彼にとってはレイトレーシングのコードは、資料を何も調べずとも書けるそこそこに複雑なコードという位置づけのようです。 そのため、彼にとってはレイトレーシングを新しい言語で書くことで、言語仕様にのみ問題を絞って勉強することができるわけです。仮に実行結果がマズかったとしても、それは言語仕様の理解の問題であり、アルゴリズム自体に問題な
プログラミングスクールへの期待と提案について - ペパボテックブログ
CTOのあんちぽです。このエントリでは、昨今隆盛しているプログラミングスクールに対して期待していることと提案について、エンジニア採用を担当する者として述べたいと思います。 このエントリの前提としての私の考え まずCTOとして、プログラミング教育全般に対する私（およびペパボとして）の考え方を述べます。我々は「いるだけで成長できる環境」を謳い、エンジニア教育に熱心に取り組んでいる企業であると自負しています（少なくとも相対的には）。また、インターネット産業の担い手として、この業界に多くの方がエンジニアとして活躍の場を見いだせることを心から願っていますし、微力ながら貢献してもいると思っています。 そのような我々ですので、昨今のプログラミングスクールの隆盛について、非常に好ましく思っています。特に私のような世代は、見様見真似で必死にやってきてなんとかいまがあるという感じでプログラマになりましたが、昨
「オブジェクト指向とは、現実世界を正しく捉えること」という理解はデメリットのほうが大きい
これは「オブジェクト指向」がよくわかってない人の書いたポエムである。 そういうのが嫌いな人はお帰りください。 はじめに リンクは貼らないが「オブジェクト指向の本質とは現実を正しく捉えること」と書かれている記事（以下、元記事）がバズった。 私は正直「オブジェクト指向」の何たるかを理解しているとは言い難い。 しかし、そんな私でも元記事がいくつかの点でおかしい、もっと厳しくいうと開発現場に混乱をもたらす可能性を持っていることは理解できる。そこでこの記事では「オブジェクト指向とは〇〇である」という言及は行わずに、元記事の問題点を指摘するに留める。 長方形と正方形の例 オブジェクト指向プログラミングと現実世界の話というとBobおじさんが『アジャイルソフトウェア開発の奥義』に書いた正方形と長方形の話が有名だ。 話は簡単だ。「正方形クラスは長方形クラスを継承するべきか？」というものだ。 少しだけ詳しく見
「プライベートでは一切勉強したくない」と言っていた社員のこと - 株式会社アクシア
アクシアはシステム開発を事業としている会社であり、社員の多くはプログラマーです。プログラマーは技術職であり、一般論としては常に最新技術を学んでいかなければならないと言われています。 しかしアクシアにはかつて、プライベートでは一切勉強したくないという社員がいました（仮にAさんと呼ぶこととします）。プライベートで勉強することは貴重な人生の時間の無駄遣いであり、絶対に勉強はしたくはないとそのAさんは言っていました。 私自身はそういう人生を否定するつもりは全くありませんし、それも一つの立派な選択だと思います。要は自分にとって充実した人生を送ることができれば良いわけですから。 しかしながらエンジニアを雇用するシステム開発会社の経営者としては、色々と考えさせられることもありました。今日はそのあたりの想いについて書いてみたいと思います。 エンジニアとして「勉強をしない」という選択 アクシアでは基本的に社
したたか？天然？なんかうまくやってるITエンジニアの生存戦略 / #oso2018
オープンセミナー2018@岡山の発表資料です。 オープンセミナー2018@岡山 https://oso.connpass.com/event/82152/ 岡山で「ITエンジニアの生存戦略」について話してきました http://blog.jnito.com/entry/2018/05/14/114740 ---------- Twitter https://twitter.com/jnchito Blog http://blog.jnito.com/ プロを目指す人のためのRuby入門｜技術評論社 http://gihyo.jp/book/2017/978-4-7741-9397-7 Everyday Rails - RSpecによるRailsテスト入門 https://leanpub.com/everydayrailsrspec-jp 株式会社ソニックガーデン https://www.s
【GitHub超初心者入門】この前初めてGitHubを使い始めたエンジニア見習いが書くGitHubの使い方と実践～とりあえず一緒に動かしてみようぜ！～ - Qiita
【GitHub超初心者入門】この前初めてGitHubを使い始めたエンジニア見習いが書くGitHubの使い方と実践～とりあえず一緒に動かしてみようぜ！～GitHub初心者入門新人プログラマ応援 たくさんの「LGTM」ありがとうございます。 ちょっと別視点からバージョン管理システムの記事を書いてみました。 そちらもよろしければごらんくださいませ。 【Git】オレならこう説明する！Git初心者への用語説明 後、個人ブログもはじめましたのでよろしければ（宣伝） 3年ぶりにこの記事の続きをnoteで書きました。 https://note.mu/nahito/n/nded6e4dd7382 はじめに 「勝利にコミットせよ！」「結果にコミットせよ！」 ……は？ 何を言ってるかさっぱりわかりません． コミットって何？つーかコミットって日本語で言うと何？言ってみろよ！！！ そんなエンジニア見習いがとうとうG
【田中圭一連載『MOTHER』編】任天堂を動かした、糸井重里の熱意「なぜ俺はゲームを作ってない！」――本職の「言葉」、岩田聡の「突破力」が生んだ、後世語り継がれる傑作
1962年5月4日大阪府枚方市生まれ。近畿大学法学部卒業。大学在学中の83年、小池一夫劇画村塾（神戸校）に第一期生として入学。翌84年、『ミスターカワード』（『コミック劇画村塾』掲載）で漫画家デビュー。86年開始の『ドクター秩父山』（『コミック劇画村塾』ほかで連載）がアニメ化されるなどの人気を得る。大学卒業後はおもちゃ会社に就職。『週刊少年サンデー』にも不定期で『昆虫物語ピースケの冒険』（89〜91年）を連載した。パロディを主に題材とした同人誌も創作。最新刊は2017年1月刊『うつヌケ』（KADOKAWA刊）、『田中圭一の「ペンと箸」』（小学館）。 【『MOTHER』コラボデザイン「ほぼ日手帳2018年版」が好評発売中！】 多くの人が愛用している「ほぼ日手帳」。その2018年版には、なんと『MOTHER』コラボデザインが3種類も登場！ 『MOTHER2』の終盤に冒険する不思議な場所「マジカ
柏市が市内全小学校でプログラミング授業を始められた理由
柏市が市内全小学校でプログラミング授業を始められた理由 ～118学級3600人がプログラミング授業を体験～ 2020年から、小学校でのプログラミング教育が必修化される。もちろんそんなことは知っている。ただ、どうやったらいいのか分からないだけだ。という教育委員会、学校関係者が多いことだろう。当然である。昨年春に政府が決定して、今年3月の次期学習指導要領で告示されたのだから、教育界の周期で言えば「寝耳に水」の状態だろう。 そんな中、昨年夏「市内全小学校の4年生にプログラミング教育を実施する」という計画を決定。本年度からすでに、活動を開始している自治体がある。千葉県柏市だ。プログラミング学習の授業を見学させて欲しいとお願いしたところ、承諾が得られたので、柏市立旭東小学校を訪ねた。 案内してくれたのは、柏市教育委員会学校教育課の副参事で学校企画を担当する佐和伸明さん。 開口一番、一番知りたかったこ
「ついカッとなって……」取り組んだ"開発者のための開発"で業務効率を改善させた話 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ついカッとなって……」取り組んだ 開発者のための開発 で業務効率を改善させた話 ソフトウェアエンジニアの醍醐味は、華々しい働き方のみにあるものではありません。開発者のための開発など、地味かもしれないけど楽しくやりがいのある仕事について紹介します。 アプリケーションエンジニアの id:aereal です。はてなで働いています。 昨今は機械学習などが半ばバズワードと化し、「トレンドを追いかけなければソフトウェアエンジニアとして生き残れないのではないか」という漠然とした不安に襲われることはないでしょうか。 これという専門分野の技術を活かし、所属する企業やひいては社会へ貢献するというあり方は、技術職として華があり憧れを誘うものです。 しかしソフトウェアエンジニアの醍醐味はそういった華々しい働き方のみにあるものではなく、むしろその他の様々な分野にたくさん散りばめられていると筆者は考えます。 この記
新卒の子にどこまで勉強すれば良いですかね？と聞かれた件 - Qiita
ちょっと、簡単に答えられなかったので、休み中にまとめました。 「どこまで勉強すれば良いか？」 という質問には、 自分の立ち位置や、今後の目標など関わるので、 それらを踏まえて考える必要があると思います。 職種によっても違いますが、質問された時の状況は、 Web系エンジニアが新卒の子に聞かれた形なので、 考慮いただきたいです。 また、そもそも、どんな背景をもったやつが書いてるんだ？と思う方も いらっしゃるかと思いましたので、簡単に自己紹介してから書きます。 書いている人の自己紹介 現在33歳で、エンジニアスタートしたのが、 2005年08月だったので、エンジニア歴は11年となります。 ほとんどの現場がデスマーチ状態だったので、2ヶ月くらい前に転職して、 現在はホワイトな会社のリクルート住まいカンパニーで、PHPを書いています。 言語歴としては、最初にJP1スクリプトを１年半くらいやって、次に
「勝手に忙しくしている人」にあまり同情の余地はない。
ビジネスマンは忙しい。 朝出社して、前日に残した仕事の続きをしていると、メールや電話がかかってきて、次々と小さなタスクが積み上げられる。 なんとかそれらをこなしていると昼休みだ。急いで昼ごはんを掻きこんでいると、あれもこれもやらなければ、と気づく。 席に戻った彼は、頭の中でタスクを整理して、優先順位を決め、処理していく。 この調子だと、今日も残業かもしれない。そういえば有休もしばらくとっていない。 ふと窓辺にいる課長を見ると、緩慢な動作で書類に目を通したり、思いついたようにどこかに電話をかけて、どうでもいい話題で盛り上がったりしている。 どう見ても暇そうである。 それなのに、給料はこちらのほうが安いときている。自分に対する評価は正当なのだろうか？ このような光景を会社の中で見かけることは珍しくない。 かわいそうな話だと思う。自分もそうだ、と忙しい彼に感情移入できる人もいるかもしれない。 し
エンジニアに必要なスキルは - まなめはうす
エンジニアにとって最も大切なことは、お腹が出ていないこと。 と、１５年前に私の見ていたサイト界隈で決着がついたのですが、エンジニアである私が必要だなと思うスキルって自分の中では時折変わっているので並べてみます。 可読性の高さ プログラムを書く仕事に就いたこともあって、一番大切なことは可読性の高さだと上司に面接で熱く語ったのは良い思い出です。技術屋でない上司はちんぷんかんぷんのようでしたが、バグを出さないためには、誰が見ても読みやすいコードを書くことによりバグも見つけやすくなるし、そこまで気遣いができればバグを残すことはなくなると思ってました。 この難しさは、自分にとって読みやすいというだけでなく、誰が見ても読みやすいということです。そのために、個性を取り除いていく作業を良くしたものです。 丁寧であること プログラムを書いたり、レビューをするようになったり、繰り返しているうちに次第に思うよう
優秀な外国人技術者を使い捨てるSIer
むかついているがどうにもできない。そのことにさらにむかついている。 背景俺は新卒で入ったSIerに勤めて数年になる。 うちの会社は社員数も売上高も数千の中規模SIだ。いつからかわからないが中国にも支社があり、現地の技術者を採用したりもしている。（こうした実績からグローバル企業を謳ったりもしている…） 新卒でも中国人を採用していて俺の同期には5人いた。 同期の中国人技術者の優秀さこの会社に入って最初の合同研修期間で彼らと接することになったのだがまずスペックの高さに驚いた。 まず3ヶ国語を扱える。中国語はもちろんネイティブ、英語はビジネスレベルで習得しており、個人差はあるもののみんな日本語での日常会話に支障はない。外国人に難しいとされる日本語の読み書きも、漢字をある程度知っているだけあってアルファベット圏の人々より習得が早いらしい。 全員バリバリのコンピュータサイエンス出身。 俺は文系学部出身
なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
バグなどの謎の現象に立ち向かうも闇が濃く、どうしても沼から脱出できない時に見るフローチャート - Thanks Driven Life
ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「GitとGitHub用語」の可愛いイラストを使用した解説に対して圧倒的わかりやすさを感じる人たち
サインコサインあそび
今時の作り手に向けた「サービス終了したら遊べなくなるゲームしか作ってないと心が折れる」との言葉が重い - Togetterまとめ
