[B! programming][疑義あり] vanbraamのブックマーク

もうじき40代なかばを迎えるプログラマーの遺言（少し追記）(もうちょっと追記）(さらにもうちょっと追記)

世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに﹁あぁ、これが35再定年説の根拠か﹂というものがなんかちらほら見えるようになってきたので書いてみようと思った。世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる︵ブラック的な意味ではなく︶。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説にしか映らないだろう。だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたく

vanbraam 2020/11/15

"悲しいことに自分たちの振りかざす論理が、単なる正論、飛躍、極論、屁理屈、と言ったものであることに気づけない人も結構多い"<これブーメランになるんじゃないかな

リンク

エンジニアに独学を期待するのはもう時代遅れだと思う。 - ヨーロッパで働くIT土方社長のブログ

www.ntt.com これを見てちょっと最近の流れと違うなぁとしみじみ思ったので全力で反論してみる。。僕自身は81年代生まれ、小学校6年生のときにPC98シリーズのN88Basicで独学でBasicから入って、中高とDirectX使ってゲーム作ったりして、大学のときにバイトで実務のプログラムを初めて〜、と何故かまぁ小さいながらも経営者として傍らまだ炎上した案件とかに入って消火活動に勤しんでたりしてる。まぁ後半はどうでもいいけど、この世代では日本海外とわず独学で勉強するのは至って普通だと思う。クロアチアだと勿論PC98じゃなくてAmigaとかドイツ製のPCが主流のよう。で、一方で最近の新入社員たちを見てると最初からスクールに通って、大学で授業を真面目にうけて、インターンでメンターに面倒を見てもらって、バイトも常にメンターがいつつ実務に関わってって流れが普通。プログラミングは常に勉強とし

vanbraam 2020/10/14

ITに限らず,デザイナーとか料理人とかの技術系の職種って,やる気のあるやつは独学_も_するのが普通なのでは? 独学に"期待"するのはダメだし,頼るのは論外だが, b:id:entry:4692683577746250626 は別にそんな事言ってないと思う

リンク

TypeScript誕生の背景 | TypeScript入門『サバイバルTypeScript』

TypeScriptは、JavaScriptでも大規模なアプリケーションを開発しやすくすることを目的に開発されたプログラミング言語です。確かにJavaScriptは元々、大規模な開発を想定した設計ではありませんでした。それでも、JavaScript自体が進化して、大規模開発に対応してゆけば良かったはずです。しかし、実際はそううまくは行きませんでした。代わりに、大規模開発の一部はTypeScriptが引き受けることになったのです。なぜ、そうなったのでしょうか？その答えはJavaScriptの歴史にあります。TypeScriptが必要な発明で、そして、今もなお必要とされている理由が見えてきます。それでは、TypeScript誕生以前の歴史をひも解いていきましょう。 1990年代JavaScriptの誕生JavaScript誕生以前は、簡単なフォームのバリデーションをするのも、サーバーサ

vanbraam 2020/07/06

TypeScriptを作ったMicrosoftへの配慮かもしれないが,JavaScriptのIE独自仕様という邪悪な存在がJavaScriptの停滞をもたらしたことに触れないのはダメでは

リンク

【JavaScript】本日未明、[ if - else ]さんが死体で発見され... - Qiita

﹁な、なんじゃこりゃあああぁあっtっt！！！！﹂・・・・・・・・・読みやすいコードを書きたい複雑な条件分岐は、書いている本人も、後からそれを読む他人も非常に疲れるものです。令和プログラマー*1である私自身、なるべく気を付けようと思っていますが、ついつい条件反射でif-elseを書いてしまいそうになります。︵*1: 令和になってからプログラミングを知った人。初心者のこと。︶ if - elseを使わない条件分岐のレパートリーを増やす if - else文が絶対ダメということでは決してありません。たくさんのレパートリー、つまり引き出しを持っておけば、適切な読みやすいコードをかける可能性が上がるかなと思うのです。文と式 JavaScriptには﹁文﹂と﹁式﹂があります。この2つの違いを意識することが重要ではないかと思います。﹁文﹂は、マシンへの命令です。﹁式﹂は数学的な値

vanbraam 2020/07/05

3項演算子,evilとする人もいて,Goでは不採用になってたりするので,安易に勧めて良いのだろうか? 最低限Bob PikeやKen Thompsonに喧嘩売る覚悟が必要では?; つまらない話だが"死体"は故人が未特定の場合. 特定済の場合は"遺体"

リンク

オブジェクト指向プログラミングの現在・過去・未来

1995年まで：イノベータとアーリーアダプターの時代； 1995-2005 ：　オブジェクト指向ブームと混乱の始まり；　2005-2015 ：　さらなる混乱と収束の兆し；　2015- ; 現在の状況とこれからの２０年Read less

vanbraam 2020/02/17

動的型付け言語を"型のない言語"呼ばわりしてる時点で,この人の"型"に関する理解もかなり疑わしい物だと思う

リンク

未来のプログラミングについて再考（機械学習とソフトウェア2.0、配管工プログラマ、オープンソースでは十分でない？） - YAMDAS現更新履歴

昨年のエントリだが、その後現在までマイク・ルキダス（Mike Loukides、O'Reilly Media のコンテンツ戦略担当副社長）の文章を追って、これを書いていた当時ワタシが理解していなかった文脈、そしてそれに対応するニュースや問題意識が見えてきたところもあるのでつらつらと書いておきたい。こちらは2019年末に、マイク・ルキダスが O'Reilly Media のチーフ・データサイエンティストである Ben Lorica と共に書いたエントリだが、2020年3月に開催される O'Reilly Strata Data & AI Conference に向けた露払いである。ワタシはタイトルだけ見て、「ソフトウェア2.0？今さら〇〇2.0は古いだろー」と思ったのだが、これは Tesla で AI 部門長を務める機械学習の専門家 Andrej Karpathy が2017年11月に公

vanbraam 2020/02/10

OSSと"再ビルド不要のAPI"って独立事項だと思うが.別にソースを公開することがカスタマイズ容易性の阻害に繋がるとは思えない;AI時代のプログラミングがどうなるかは面白そうだが,結局人間の出力能力が問題になりそう

リンク

プログラミング言語はひとつマスターすれば他もできる？ - t-hom’s diary

プログラミングでは、ひとつの言語をマスターすれば、どんな言語でも使えると言われている。この言説には賛否あるけど、ある意味正しくて、ある意味間違いだと思う。より正確に言えば、新しく学ぶ言語と既にマスターしている言語に共通する概念についてはスムーズに移行できるということだ。たとえば変数・分岐・繰り返し・比較演算なんかは、大半の言語が備えている共通概念である。言語によって作法やスタイルが異なるだけで考え方は同じなので、新しく学習する言語でこれらを使いこなすのは難しくない。仮にVBAを100%マスターしているなら、Pythonの学習範囲はPython特有の部分だけで済む。まあそうは言ってもなかなか一つの言語をマスターするのは難しい。 VBAの学習割合が少なければ、Pythonをマスターするための学習範囲はより広くなる。じゃあまずはVBAを極めよう！と考えるかもしれないがそれも早計である

vanbraam 2019/09/17

「_2つ_使えれば_だいたい_他も何とかなる」じゃないかな.1つしか知らない人は(computer scienceを先に学んだ人を除いて)"共通概念"という概念をまず理解する必要がある

リンク

おそらく先がない5つのプログラミング言語？ - YAMDAS現更新履歴

おそらく先がない5つのプログラミング言語、といういろいろと怒りをかいそうな記事だが、どうせワタシが愛するC言語なんかがまたやり玉に挙がってるんだろうと見たら、一番最初に Ruby が挙がっている…… この記事は TIOBE や RedMonk のプログラミング言語ランキングに Dice 独自の求人票情報を加味してるようだが、Ruby は落ち目という認識らしい。うーむ。それ以外には Haskell、Objective-C、R、そして Perl が挙げられていて、この手の記事の定番といえる Perl、Swift 誕生後やはり定番である Objective-C はそうですかという感じだが、ビッグデータの時代に人気を高めたR言語ですら、Python に追いやられつつあるというのはそうなんでしょうね。それにしても Ruby が先がないという意見には異論が出るだろう。ネタ元は Slashd

vanbraam 2019/08/06

こういう記事(特に参照されてる元記事のようなやつ)を真に受けて,勉強する言語を決めるような人って,だいたいプログラマーとしてはダメな印象.プログラミング言語は必要に応じて学んで使い分けるものでしかない

リンク

[翻訳]あなたがプログラミングに向いていない10のサイン - Qiita

※この記事はJonathan Bluks氏の「10 Signs You Will Suck at Programming」を翻訳したものです。Mediumのコメント欄より翻訳の許可を頂きました。ありがとうございます。より多くのステッカーは、より多くの成長にはなりません。最近、RedditやQuoraで「自分がプログラマとして成功できるか、どうすれば分かりますか？」という質問をよく見かけます。キャリアチェンジを検討したり、あるいはソフトウェア開発に興味があったりするのであれば、それはごく自然な疑問です。コンピュータに関する正式なトレーニングを受けていない場合、人々はプログラマになることに大きな心理的障壁があると思います。プログラミングが苦手であれば、あなたは自分がプログラマとして才能が無い人だと思うのは自然な考えです。もしあなたが俳優になりたいと思っていて、自分は演技が得意かどうかを疑

vanbraam 2019/03/22

訳が残念.例えば"suck at"は"向いていない"というより"嫌気が差す"の方が近いのでは?;10+1のどれかに適合しても,そういう理由でプログラミングを止めたくなった時に自戒する為のリストとして使う方が良さそう

リンク

クソコードはエンジニアを貧乏にする｜ミノ駆動

何が書かれているのか理解が難しく、イレギュラーな方法で裏技的に実装され、ちょっと触ればバグと化す、クソコード。プログラマ諸氏なら誰しもが見たことのあるクソ忌々しいアイツだ。クソコードはエンジニアを貧乏にしてしまう。なぜ貧乏になってしまうのか、その理由について、怒りをぶつけながら以下に書き連ねる。本記事の構成■理由①‥プロダクトが利益を出せなくなる ■理由②‥エンジニアが資産蓄積できなくなる　︵←ココ重要︶ ■クソコードを滅ぼし豊かになろう ■ソフトウェア開発に携わる方々へ理由①‥プロダクトが利益を出せなくなるまずこちらの理由は簡単だ。3項目に分けて説明する。︻クソコードは読みにくい︼どんなロジックなのか理解が容易ではない。ロジックそのものは簡単であっても、tmpと名付けられた正体不明な変数、非推奨なAPIによる意図不明な実装などにより、読み解くのを難しくさせてしまう。﹁クソ

vanbraam 2019/03/22

クソコードの問題点には同意するが,それと貧乏との関係については牽強付会さを感じる

リンク

還暦COBOLはお荷物なのか？

1959年に誕生したプログラミング言語のCOBOL︵Common Business Oriented Language︶は、2019年で生誕60周年を迎えた。人でいえば還暦や定年に当たり、これから第二の人生を歩んでもおかしくない年数である。このままひっそりとした余生を過ごすと思いきや、最近COBOL関連のニュースに事欠かない。例えば、2019年1月24日には情報処理推進機構︵IPA︶が基本情報技術者試験を見直し、COBOLを午後試験の選択言語から外すことを発表した。また、厚生労働省の毎月勤労統計の問題も見過ごせない。厚生労働省が公表した報告書によれば、過去に不適切な調査が行われた原因はCOBOL エンジニア不足による﹁プログラムのチェック不足にある﹂という。最近のCOBOL関連ニュースには、何かとネガティブなイメージが付きまとう。まるで﹁お荷物﹂といった扱いだ。COBOL エンジニアが少な

vanbraam 2019/03/04

よく言われる「仕様書が残ってない」等はプログラミング言語の責任ではない;自動テストの仕組みがないのは現代言語としてはかなりマイナス.記事に書かれてる"課題"は的外れ感強い

リンク

コードレビューが好きになるプログラミングの原則 - Speaker Deck

Web Developers Meetup Gotanda ～ MC Open Lab. #6 ～で利用した資料です。 https://memberscareer.connpass.com/event/106254/

vanbraam 2018/11/27

OCP:拡張に対してopenで,修正に対してclosed;KISS:Keep It Simple, Stupidがオリジナル;冪等性を求める理由は"操作の順序を意識しなくて良い"の方が適切では?;そもそも理由を示さないレビューはダメだと思う

リンク

500+のサーバーで動く LINE Ads PlatformをささえるSpring

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 Spring Fest 2018

vanbraam 2018/11/02

"real time bidding"という言葉に騙されたけど,広告主は事前に条件付きbidを積んでいて,SSPからrequestが来たら条件に適合する最高値のbidを選択する,という理解で合ってるのかな?人間が50msでbidできるわけはないし

リンク

女性システムエンジニアから見たIT業界の風景 - 意識低い系ドットコム

﹁きつい﹂﹁帰れない﹂﹁給料が安い﹂の新３Kなどとも呼ばれ、あまり良いイメージの無いIT業界ですが︵少しずつ良くなってはいるのですが・・・︶、最近は女性エンジニアも増えています。女性の目にはこの業界はどんな風に映るのでしょうか？女性システムエンジニア︵元︶の方に体験談を寄稿していただきました。 IT業界あるある漫画﹁仕様書なんてただの飾りです﹂＆﹁IT系エンジニアのアンニュイな午後﹂ ---------------------- [ 寄稿記事ここから ] ---------------------- SEを目指したきっかけ私はある日突然思いました。﹁そうだ。SEになろう。﹂と。大学は文系。前職は銀行員。そんな私がSEになろうと思った理由は、実のところ、﹁パソコンが苦手﹂だからでした。﹁え？　苦手だから？　得意じゃなくて？﹂　はい。苦手だったから、です。時代はIT。IoTやら、AI

vanbraam 2018/08/19

"プログラミング自体は割とすぐにできるようになりました","困難を感じることはありませんでした"に違和感.非常に優秀な人か,単なるコピペグラマーになったのをプログラマーになったと勘違いしているかのどちらかでは?

リンク

無責任な"not for me"発言は迷惑なのでやめてほしい - lacolaco

愚痴。最近特定の技術やライブラリ、ツールなどに対して、﹁自分には合わなかった﹂のような発言をする人をよく見かける。ちょっと前だと﹁○○はクソ﹂のような直接的なdisが目立っていた気がするので、少しは丸くなったつもりなのかもしれないが、 Angularというひとつの技術のユーザーコミュニティを主催する僕としては余計に迷惑だ。もっと慎重になれ medium.com AirbnbがReact Nativeを使うのをやめた記事、これは本当に偉い。技術選定を行い、結果的にマッチしなかった、というレポートには、最低限次の項目が必要だと考えている。開発の目的選定理由マッチしなかった理由このどれが欠けてもいけない。単に言葉遣いが柔らかいだけでdisと変わりないどころか、下手するとFUDにすらなり得る。 FUD - Wikipedia FUD︵英: Fear, Uncertainty and

vanbraam 2018/08/09

記事消えてる.残念

リンク

「悪い方が良い」原則と僕の体験談｜Rui Ueyama

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

vanbraam 2018/04/06

入力チェックをサボった結果脆弱性に繋がる例はかなり多いと思うのだが,そういうチェックも阻止したのだろうか?だとしたら,阻止しても問題ないと判断した理由は何なのだろうか?

リンク

希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談（６）

テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし

vanbraam 2018/04/05

何かモヤモヤする;テストを書く理由なんて"テスト(の様な非生産的な作業)を手動で何度も実施したくないから"で十分では."変更を自信を持って行える"はテストの最大の効用だが,唯一の効用ではないと思う

リンク

nilが欲しいからと言ってむやみにポインタを使うとひどい目にあう話 - moriyoshiの日記

スマートフォンアプリ側の実装担当として少し関わっているあるβ版のサービスで、奇妙だが比較的クリティカルな問題が発生していた。それもメッセージが関係ない人間に届くというものであった。なんとなくその問題を担当することになったが、常に状況が再現するわけではなく、他の仕事もあったので、問題への見当を付けられないまましばらく過ごしてしまった。そのメッセージを送信する部分はサーバサイドのコードで、Goで書かれていた。そのコードのエッセンスを抽出すると、以下のようになる。 package main import ( "fmt" "sync" ) type User struct { Id int Name string } type Mail struct {Title string UserId *int } func sendMail(mail Mail, wg *sync.WaitGro