35歳を迎えたCTOが35歳定年説について考えた - そーだいなるらくがき帳
先月、35歳になった。 35歳定年説は「全員に一致する法則ではない」というのは一般的な認識になっている。 前職の同僚で同世代である id:motemen に聞いたところ「そんな事を意識したことなかった」という回答をもらったこともある。 しかし、実際に自分が35歳になると「自分は他人事ではない」という感覚だけがある。 そこで今日はそのことについて考えていきたい。 コードを書くということ コードを書くという行為は年齢関係なく続けていける。 しかし「仕事でコードを書き続ける」となると事情が変わる。 まず費用対効果として自分がコードを書くことが正しいのか？という問題とぶつかる。我々のプログラマーとしての仕事を奪うのはAIではない。いつの時代も 優秀な若者 だ。 そんな若者と比較した時、我々がコードを書くことが若者がコードを書くことよりも費用対効果がある場合はどんな場合だろうか？やはり経験が活かせる
正しさとGo - Qiita
はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
変数とかを英語にするとわかりにくくないですか？
プログラムを独学で勉強している初心者です（２ヶ月くらい） ちょっとした疑問があり、質問させていただきます。 プログラムのサイトなどには、変数などの名称には英語を使うべきと書かれています。 これはなぜなのでしょうか？ はっきり言って、この風習があるために勉強で困っています。 勉強のためにサンプルコードなどを見ていても、英単語が並んでいると、 どれがプログラム特有の命令で、どれがプログラム記述者が自由につけた変数名なのかが わかりにくいのです。 変数は変数であることがはっきりわかったほうが便利だと思うのです。 プログラムに慣れている人にはそんな必要ないのでしょうが… 自分でコードを書く時には、あとから自分でわからなくならないように 変数名には必ず「h_」をつけるようにしています。 h_speed とか h_count とか。 英語にするべき理由と、初心者のうちだけでも変数がわかりやすくするよう
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
PHPerの書くコードの保守性・管理性が劇的に上がるのスマートな方法
みなさんお仕事の進捗どうですか？ 今日は ふと今こそ保守性・管理性が劇的に上がるPHPのスマートなコードの書き方まとめを俺が書くときじゃないだろうか。 — そーだい＠初代ALF (@soudai1025) 2014, 8月 12 こんな軽はずみな発言をしてしまったが故にネットで触れては行けない3大炎上案件について触れる。 ※ネットで触れては行けない3大炎上案件とは？ Excel関連（スクショとか） 宗教（エディタとか） PHP のこと。 で今話題の元ネタを既に@sue445さんが魚拓してくれてる。 「Hello! my name is 404 お探しのページはありませんでした！申し訳ありません。。」 http://t.co/MS8Xy0bCMz 魚拓とっててよかったｗ http://t.co/UvG3gzsPul — sue445 (@sue445) 2014, 8月 12 （炎上したら即
例外設計の話
例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで
株式会社エスプラニングを退職しました - やさしいデスマーチ
7月31日付で2年半ほど在籍した株式会社エスプラニングを退職しました。退職系のエントリーはブクマが稼げると聞いて、状況報告を書こうかなと思います。 前職でやっていたこと 前職は主にJavaによるアプリケーション開発が主業務でしたが、珍しくWeb系というわけでもありません。入社した頃は、Swingでのデスクトップアプリケーションが主プロダクトでした。最近はWebアプリケーションやスマフォ系もやっています。そんな会社で自分が行ってきたことは、開発環境の整備、コード品質の向上、プロジェクト全体の進め方の改善などです。 具体的には、ユニットテスト、読みやすいコード、リファクタリング、レビュー、KPT、カンバン、Trac/Redmine、バージョン管理、継続的インテグレーション、ユースケース駆動開発などなどです。 ぶっちゃけ言えば、入社した当時はお世辞にも技術レベルは高いと言えませんでした。バージョ
怠け者で愚かな人間ほど優秀なプログラマーに向いている理由
By slworking2 優秀であり仕事を迅速にこなす人は、よく働き、頭の回転も早そうですが、プログラミングの分野においては話が別のようです。ブロガーのPhilip Lenssenさんによれば、優秀なプログラマーほど怠惰で愚かでなければならないとのことで、その理由について公開しています。 Why Good Programmers Are Lazy and Dumb http://blogoscoped.com/archive/2005-08-24-n14.html 怠け者のプログラマーは自分の仕事を減らしたいがために、便利なツールやソフトを作成することがあります。また、単調で、繰り返されるだけのコードを書かず、余分なものをそぎ落とす傾向があるとのこと。自分が楽をしたいがために生み出される努力から作り出されたツールは、生産性をあげるのに一役買ってくれるでしょう。 By dchrisoh ま
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
優れたプログラマーの7つの資質
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 優秀なプログラマーであるためには、自分の持つスキル、経験、知識から、動くコードを生産するための資質を持っている必要がある。技術的なスキルは持っていても、必要な資質を持っていないために優秀なプログラマーになれない人もいる。この記事では、偉大なプログラマーになるために必要な7つの資質を紹介する。 1．自発的に新しい技術的・非技術的スキルを習得する だめなプログラマーは、どうしても必要になった時にしか学ぼうとしない。よいプログラマーは、積極的に新しい技術的スキルを習得する。偉大なプログラマーは自ら新しい技術的なスキルを学ぶだけでなく、技術以外のスキルも学び、ほかの人なら考えもしないような情報源に対してもオープンな態度で接する。 具体的に例を挙
大江戸 Ruby 会議03で、某レシピサイトの Ruby 1.9.3 対応で苦労した点を共有しました - 恒温動物の生活ログ
こんばんは。今日は20時に退社しました。 先日、大江戸 Ruby 会議 03 が、深川江戸資料館で開催されました。大江戸 Ruby 会議は、Asakusa.rb のメンバーの生活発表会として位置づけられている地域 Ruby 会議です。そこで私は Ninja Talks の1枠を頂戴し、普段の仕事の話をしてきました。内容は、勤務先が運営するレシピ共有サイトが使用している Ruby のバージョンを Ruby Enterprise Edition から Ruby 1.9.3 へ移行する際に苦労した事柄の共有です。 スライド↓ 時間と内容の関係で、会議では言わなかった話があります。 ここで紹介されているコードのうち、"Before" に当たるものの中には、皆さんが一目見て「酷いなぁ」と感じるものがあると思います。中には、こんな書き方ができたのか！と驚くようなものもあるでしょう。 しかし、忘れて欲し
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
動的型とか静的型の話の前に「作者の気持ち」を考えろ - mizchi log
自分の思考を整理する意味でも、件のアレについて考えたことを書いてみる。 変数に型がないということの利点について考える - サンプルコードによるPerl入門 http://d.hatena.ne.jp/perlcodesample/20130227/1361928810 この件に触れることはプログラマとしての中二病である。恥ずかしい。マジレス乙だ。 でも気づいたら5000文字も書いてしまったし、公開して酒のんで寝る。 型のフローは機械のためだけでなく、人間に対するものでもある 最近TypeScriptを書いている。こいつを使って、二次元座標上で二点間を求める関数、getDistanceを定義してみよう。 interface IPoint { x: Number; y: Number; } var getDistance = (a:IPoint, b:IPoint): Number => Ma
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.smaroomch.net/programing-hituyounakoto/
https://www.gembook.org/benefits_of_dynamic_typing.html
Xamarin、C#言語によるiOS/Androidアプリ開発を実現する“Xamarin 2.0”を発表